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

Reimplement publish-types script with recast #20316

Merged
merged 2 commits into from
Dec 8, 2022
Merged

Conversation

chriskrycho
Copy link
Contributor

This is far more robust against all the kinds of things our modules do:

  • It supports having declare module and similar in the input source.
  • It does not do dumb string replacement to remove declare, which can easily remove things from comments or the like.
  • It correctly handles relative imports (./ and chains of ../).

For this to work correctly, we needed to have more recent versions of the Babel parser, so this freshens the lock file for all @babel/* dependencies. It also adds recast and drops magic-string.

This has been tested by enabling more than 50% of the unpublished modules; the resulting output is correct from the point of view of this script but exposes a number of fixes we will need to make for our types as we enable more and more of those.

@chriskrycho chriskrycho added internal TypeScript Work on Ember’s types labels Dec 8, 2022
This is far more robust against all the kinds of things our modules do:

- It supports having `declare module` and similar in the input source.
- It does not do dumb string replacement to remove `declare`, which can
  easily remove things from comments or the like.
- It correctly handles relative imports (`./` and chains of `../`).

For this to work correctly, we needed to have more recent versions of
the Babel parser, so this freshens the lock file for all `@babel/*` dependencies. It also adds `recast` and drops `magic-string`.

This has been tested by enabling more than 50% of the unpublished
modules; the resulting output is correct from the point of view of this
script but exposes a number of fixes we will need to make for our types
as we enable more and more of those.
Comment on lines +85 to +86
> = DIRegistry[Type][Name] extends infer RegistryEntry extends object
? FactoryManager<RegistryEntry>
Copy link
Contributor Author

@chriskrycho chriskrycho Dec 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unclear why, but tsc started grumping about assignability in producing the FactoryManager type without this change.

@chriskrycho chriskrycho enabled auto-merge December 8, 2022 19:13
@chriskrycho chriskrycho merged commit 19d66a8 into master Dec 8, 2022
@chriskrycho chriskrycho deleted the recast-types branch December 8, 2022 19:25
chriskrycho added a commit that referenced this pull request Dec 9, 2022
Integrate the service registry into the `DIRegistry` introduced as part
of rationalizing the `Owner` types in PR #20271 (94276b5). This allows
`Owner.lookup('service:foo')` to resolve a `FooService` if one is set
up in the `@ember/service` module's `Registry` interface. The preview
types already used this mechanic, so this just means that when we ship
the stable (i.e. built from source) version of `@ember/service`, it
will *continue* working.

Meta: Shipping this implementation for the lookup was blocked on being
able to publish type modules with `declare module`, which was
implemented in PR #20316 (9adcd15). We will likely need to rework other
parts of the type hierarchy to support publishing from source.
chriskrycho added a commit that referenced this pull request Dec 9, 2022
Integrate the service registry into the `DIRegistry` introduced as part
of rationalizing the `Owner` types in PR #20271 (94276b5). This allows
`Owner.lookup('service:foo')` to resolve a `FooService` if one is set
up in the `@ember/service` module's `Registry` interface. The preview
types already used this mechanic (as of 5658b13), so this just means
that when we ship the stable (i.e. built from source) version of
`@ember/service`, it will *continue* working.

Meta: Shipping this implementation for the lookup was blocked on being
able to publish type modules with `declare module`, which was
implemented in PR #20316 (9adcd15). We will likely need to rework other
parts of the type hierarchy to support publishing from source.
kategengler pushed a commit that referenced this pull request Dec 12, 2022
Integrate the service registry into the `DIRegistry` introduced as part
of rationalizing the `Owner` types in PR #20271 (94276b5). This allows
`Owner.lookup('service:foo')` to resolve a `FooService` if one is set
up in the `@ember/service` module's `Registry` interface. The preview
types already used this mechanic (as of 5658b13), so this just means
that when we ship the stable (i.e. built from source) version of
`@ember/service`, it will *continue* working.

Meta: Shipping this implementation for the lookup was blocked on being
able to publish type modules with `declare module`, which was
implemented in PR #20316 (9adcd15). We will likely need to rework other
parts of the type hierarchy to support publishing from source.

(cherry picked from commit 5070508)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal TypeScript Work on Ember’s types
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants