Introduce infra to publish stable types #20275
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 tasks
There are pre-existing runtime shenanigans in `@ember/object/internals` to add debug-only errors to the class in dev builds. Those runtime shenanigans produce the need for type-level shenanigans to match: TS gets stuck here because the runtime shenanigans declare `FrameworkObject` with a class expression (rather than the usual class declaration form). That in turn means TS needs to be able to fully name the type produced by the clsas expression, which includes the `OWNER` symbol from `@glimmer/owner`. By explicitly giving the declaration a type when assigning it the class expression, instead of relying on inference, TS no longer needs to name the `OWNER` property key from the super class, eliminating the private name shenanigans. Co-authored-by: Dan Freeman <dfreeman@salsify.com>
chriskrycho
force-pushed
the
stable-types-infra
branch
from
fa3758a
to
4682c3e
Compare
This lets each config specify *only* how it actually does a build (or not!), while sharing the config explicitly. It also fixes an existing bug in the compilation settings which was not affecting *normal* TS compilation with `tsc`, but was generating noise in the `broccoli-typescript-compiler` pipeline because the packages happened to be resolved in a different order such that the `loader` "package" definition, and its declaration of the `require` module, was not present in the graph. Set it explicitly in `compilerOptiosn.paths` to fix that.
Provide a script which runs the compiler against a new tsconfig for generating types, wraps all the generated modules in `declare module` statements, and then creates an `index.d.ts` which uses side-effect style imports to expose them all, just the same as the preview types but generated from source. Critically, this infrastructure does not expose *any* stable types in and of itself. Instead, it introduces a list of all the types still in preview mode which acts as a filter, and currently *all* modules are in that filter. Stabilizing the types for a given module will mean removing modules from that list and removing the corresponding preview types definitions.
Align the text with the module docs for the stable types, clarifying the updated current status.
chriskrycho
force-pushed
the
stable-types-infra
branch
from
4682c3e
to
63e59ca
Compare
wagenet
reviewed
Nov 22, 2022
types/preview/index.d.ts
Outdated
| @module | ||
| Makes Ember's types for the packages it publishes available by importing this | ||
| path from `ember-source`: | ||
| Provides stable type definitions for Ember.js. It is maintained by hand, and |
There was a problem hiding this comment.
I'm a bit confused by the wording here.
There was a problem hiding this comment.
Doh. Good catch. Copy-paste failure.
| let moduleNameForDeclaration = moduleName.replace('/index.d.ts', ''); | ||
|
|
||
| let string = new MagicString(contents); | ||
| string.indent(' ').prepend(`declare module '${moduleNameForDeclaration}' {\n`).append('}\n'); |
There was a problem hiding this comment.
Am I correct that you're just using MagicString for these indent methods? It doesn't look like you're writing a source map.
There was a problem hiding this comment.
Ah, right. We can (if we want) switch to a more manual approach and the indent-string package, which is a bit smaller and lighter weight. I ended up here after having started there because I was trying to keep around the existing source maps that TS was generating, but I cannot see a way to do that, unfortunately.
dfreeman
reviewed
Nov 22, 2022
Co-authored-by: Dan Freeman <dfreeman@salsify.com>
dfreeman
approved these changes
Nov 22, 2022
chriskrycho
changed the title
chriskrycho
changed the title
16 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Provide a script which runs the compiler against a new tsconfig for generating types, wraps all the generated modules in
declare modulestatements, and then creates anindex.d.tswhich uses side-effect style imports to expose them all, just the same as the preview types but generated from source.Note
Critically, this infrastructure does not expose any stable types in and of itself. Instead, it introduces a list of all the types still in preview mode which acts as a filter, and currently all modules are in that filter. Stabilizing the types for a given module will mean removing modules from that list and removing the corresponding preview types definitions.
There are… some hacks involved in this, as was foretold in the PR introducing preview types (#20180). Because Ember does not ship the real packages people import from in a Node-resolveable way (and import maps are not yet stable and therefore not useful for TS in particular), the way this works is anything but preferable. Medium-term, we need to figure out how to generate module rollups which don’t require us to manually do this wrapping, but this will do the trick for now.
In support of this:
tsconfig.jsonfile by introducing a base compiler-options file which it extends, which in turn we can further extend off of for future needs.