Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] generate Signature in component blueprints #20356

Merged
merged 2 commits into from
Jan 20, 2023

Conversation

chriskrycho
Copy link
Contributor

@chriskrycho chriskrycho commented Jan 19, 2023

Since RFC 0748, Glimmer components support a Signature type which specifies any arguments they accept, any blocks they yield, and the element types to which ...attributes are applied. Incorporate the signature when generating TS blueprints for Glimmer components, including template-only components. Do not generate them for Ember (classic) components, since there are severe limitations in using classic components that way, and since we only support the Octane programming model in our TypeScript support per RFC 0800.

Unblocks #20352 and thus #20177!

Since [RFC 0748][0748], Glimmer components support a `Signature` type
which specifies any arguments they accept, any blocks they yield, and
the element types to which `...attributes` are applied. Incorporate the
signature when generating TS blueprints for Glimmer components,
including template-only components. Do *not* generate them for Ember
(classic) components, since there are severe limitations in using
classic components that way, and since we only support the Octane
programming model in our TypeScript support per [RFC 0800][0800].

[0748]: https://rfcs.emberjs.com/id/https://rfcs.emberjs.com/id/0748-glimmer-component-signature/
[0800]: https://rfcs.emberjs.com/id/https://rfcs.emberjs.com/id/0800-ts-adoption-plan/
@chriskrycho chriskrycho added enhancement TypeScript Work on Ember’s types labels Jan 19, 2023
@chriskrycho
Copy link
Contributor Author

Odd, I wonder why that didn't fail locally? I'll dig in and get that sorted.

For the fallback case, where Ember's blueprints are being executed by a
version of Ember CLI earlier than 4.3.0, the emitted blueprints *must
not* include any TypeScript types, since the CLI will not be able to
remove the types. Accordingly:

1.  Return a boolean flag from the `maybePolyfillTypeScriptBlueprints`
    helper, indicating whether the blueprint is in a mode where it can
    reliably *emit* types.

2.  Use that new helper in the component blueprint so that it can avoid
    emitting a signature type, and specifically can avoid emitting it
    as a type parameter on the class or function default export.
@chriskrycho
Copy link
Contributor Author

Fixed this up to do the right thing when in a non-TS context!

For posterity: The problem was that I updated what <%= defaultExport %> compiles to in the component blueprint. And that gets used across both blueprints and blueprints-js, where the latter is the fallback behavior we introduced to allow Ember to ship blueprints in TS while being used with versions of Ember CLI earlier than 4.3.0, where CLI landed support for TS.

Since the path we’re testing in the JS blueprints is “do we fall back correctly when we can’t do a transform and so have a .js file blueprint input?”—and we do! @cafreeman's work there was correct!—it… doesn’t transform anything. 😂 But since the new defaultExport value was something like export default class Foo extends Component<FooSignature> {}, the test correctly complained.

The solution here was to make these blueprints just a bit smarter: use the fact that we know whether we can compile TS out of the blueprints or not (we already had that capability) to emit different things in the cases where we need to—namely, here, by not emitting a signature type.

We could in the future, and very possibly should in the future, emit a JSDoc comment for the Signature in the case where we are emitting JS, which would provide useful norms for the ecosystem and useful tooling feedback as well. (If you're reading this and want to implement that, let us know—it should be straightforward now that these pieces are in place!)

@chriskrycho chriskrycho changed the title [FEATURE] generate signature in component blueprints [FEATURE] generate Signature in component blueprints Jan 20, 2023
@chriskrycho chriskrycho merged commit 1118df1 into master Jan 20, 2023
@chriskrycho chriskrycho deleted the blueprint-component-signature branch January 20, 2023 02:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement TypeScript Work on Ember’s types
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants