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

refactor: bundle types for non-APF compiler-cli package and localize/tools entry-point #45727

Conversation

devversion
Copy link
Member

With the upcoming module resolution variant in TypeScript that supports
ESM and NodeJS better, type definitions would also need to follow ESM
import semantics. i.e. relative type imports would need to also use
epxlicit .js extensions.

This is rather cumbersome and also not needed for all other other
Angular libraries/packages built with APF. In APF, types are always
bundled, so the manual .js extension is actually not needed unless
we start leveraging this resolution system for local development.

This commit switches two non-APF entry-points/packages to manual type
bundling (the runtime code is already bundled as well). This makes these
packages/entry-points compatible with the upcoming module resolution
(by eliding all relative imports basically)

Note: There is some type duplication in the compiler-cli package because
the package source code is not accounting for the public entry-point
layout.

…tools entry-point

With the upcoming module resolution variant in TypeScript that supports
ESM and NodeJS better, type definitions would also need to follow ESM
import semantics. i.e. relative type imports would need to also use
epxlicit `.js` extensions.

This is rather cumbersome and also not needed for all other other
Angular libraries/packages built with APF. In APF, types are always
bundled, so the manual `.js` extension is actually not needed unless
we start leveraging this resolution system for local development.

This commit switches two non-APF entry-points/packages to manual type
bundling (the runtime code is already bundled as well). This makes these
packages/entry-points compatible with the upcoming module resolution
(by eliding all relative imports basically)

Note: There is some type duplication in the compiler-cli package because
the package source code is not accounting for the public entry-point
layout.
…calize/tools entry-point

Fix granular compiler-cli api golden tests
@devversion
Copy link
Member Author

This was mostly an experiment, but it seems to work as expected. This will be a good temporary solution, like we leveraged in APF, when we cannot perform the actual migration to explicit extensions

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators May 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant