-
Notifications
You must be signed in to change notification settings - Fork 12k
refactor(@ngtools/webpack): use webpack resolver plugin for path mapping #11575
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -73,14 +73,14 @@ export default async function () { | |
|
||
await updateJsonFile('tsconfig.json', tsconfig => { | ||
tsconfig.compilerOptions.paths = { | ||
'@firebase/polyfill': ['@firebase/polyfill/index.ts'], | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's going on with these paths? It looks like breaking backward compatibility. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Bad test. They were failing due to a bug (which this PR fixes) rather then the intended reason. it should be failing due to non-project typescript files being pulled into the compilation which it now does. Before it was failing due to missing files. |
||
'@firebase/polyfill': ['./node_modules/@firebase/polyfill/index.ts'], | ||
}; | ||
}); | ||
await expectToFail(() => ng('build')); | ||
|
||
await updateJsonFile('tsconfig.json', tsconfig => { | ||
tsconfig.compilerOptions.paths = { | ||
'@firebase/polyfill*': ['@firebase/polyfill/index.ts'], | ||
'@firebase/polyfill*': ['./node_modules/@firebase/polyfill/index.ts'], | ||
}; | ||
}); | ||
await expectToFail(() => ng('build')); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we give up on TypeScript resolution, which fixed a load of issues and supports tsconfig's path mapping. See #7473
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm mostly curious of the two following assumptions in this PR:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another example is how we lose support for
rootDirs
, which I think we don't test for.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rootDirs
never really worked properly (if ever). It is also a fairly esoteric option and far more useful outside of bundling scenarios. However, we could also add support for it. The logic is very similar to the paths option but for relative imports.#7473 actually demonstrates some of the issues with using
resolveModuleName
. A large and ever growing list of special processing is needed to attempt to determine and further locate the correct file to be bundled. As opposed to the correct file to provide type information for TypeScript transpilation.Of note also is that the other two typescript loaders (
ts-loader
/awesome-typescript-loader
) both take the same general approach of re-implementing the algorithm.In regards to breakage, if TypeScript changed the algorithm or configuration options, it would result in a massive breaking change in regards to TypeScript projects in general. Failure of the TypeScript team to notify the user base of such a pending change in advance would result in a large percentage of existing TypeScript projects to fail. Advanced notification would mitigate the danger inherent in such a scenario.
Overall, the more ideal scenario would be if the underlying intrinsics for
resolveModuleName
within TypeScript were made public (someone alterations may also be necessary to allow for full re-usability; this would need further analysis). This could potentially allow this plugin to leverage more of the existing logic within TypeScript and limit the need to re-implement. However, the full Webpack resolver plugin approach would still be the appropriate implementation option as it allows multiple resolution attempts, the possibility of fallback to existing resolution, and integration into the webpack resolution pipeline (which could potentially contain additional custom resolution plugins).