fix(@angular/cli): keep relative migration paths during update analysis #21866
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
The original update analysis would prepend the package name to all migration collection files. This was required at the time to ensure the migration collection files would be found. The existing update logic, however, no longer requires this change but the change previously had no negative effects as both the relative and module specifier methods would successfully resolve the migrations. But with the conversion to ESM-based packages that use the package.json `exports` field, deep imports into a package are no longer possible unless the migration collection files are explicitly exported. Relative migration collection paths are now preferred since they are based off of the location of the package's `package.json` and do not require additional `exports` field entries. The original update analysis logic, unfortunately, prevent the relative paths from working as intended. Since this original logic is no longer required by the update process, it has been removed allowing the relative paths to be kept and used directly.
rxjs 6 requires directory imports which are not support in ES modules. Disabling `fullySpecified` allows Webpack to ignore cases such as this until the package can be updated to use package exports.
clydin
force-pushed
the
esm/keep-relative-update-migrations
branch
from
aa46fa1
to
12c141e
Compare
…est extensions The regular expressions based checks for TypeScript and JavaScript files used by Webpack module rules have been updated to include all current extension variations. JavaScript files can be either `.js`, `.mjs`, or `.cjs`. TypeScript files as of the upcoming version 4.5 can be either `.ts`, `.mts`, or `.cts`. Also while not officially supported by Angular, the TypeScript compiler can attempt to process any of the previous extensions with an `x` suffix which indicates a JSX/TSX file.
alan-agius4
approved these changes
Oct 5, 2021
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The original update analysis would prepend the package name to all migration collection files. This was required at the time to ensure the migration collection files would be found. The existing update logic, however, no longer requires this change but the change previously had no negative effects as both the relative and module specifier methods would successfully resolve the migrations. But with the conversion to ESM-based packages that use the package.json
exportsfield, deep imports into a package are no longer possible unless the migration collection files are explicitly exported. Relative migration collection paths are now preferred since they are based off of the location of the package'spackage.jsonand do not require additionalexportsfield entries. The original update analysis logic, unfortunately, prevent the relative paths from working as intended. Since this original logic is no longer required by the update process, it has been removed allowing the relative paths to be kept and used directly.