Uh oh!
There was an error while loading. Please reload this page.
refactor(@ngtools/webpack): use webpack resolver plugin for path mapping - #11575
Conversation
1da3017 to
fbbeb80Compare
hansl
left a comment
There was a problem hiding this comment.
That's a huge change just before release. I'd rather just revert the original buggy PR and investigate for 6.2.
| await updateJsonFile('tsconfig.json', tsconfig => { | ||
| tsconfig.compilerOptions.paths = { | ||
| '@firebase/polyfill': ['@firebase/polyfill/index.ts'], |
There was a problem hiding this comment.
What's going on with these paths? It looks like breaking backward compatibility.
There was a problem hiding this comment.
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.
clydin
commented
Jul 18, 2018
Can hold off for 6.2 or even 7.0, if prefered. This also cleans up and fixes several other behavioral discrepancies in the process. |
| // TODO: The following is used when there is more than one potential and will not be | ||
| // needed once this is turned into a full webpack resolver plugin | ||
| const moduleResolver = ts.resolveModuleName( |
There was a problem hiding this comment.
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.
I'm mostly curious of the two following assumptions in this PR:
- we implement TypeScript's resolution ourselves, without any bugs and edge cases, and
- we rely on TypeScript never updating their resolution algorithm and configurations, otherwise this will likely break.
There was a problem hiding this comment.
Another example is how we lose support for rootDirs, which I think we don't test for.
There was a problem hiding this comment.
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).
bbf1a02 to
f0065c8CompareHi @clydin! This PR has merge conflicts due to recent upstream merges. |
f0065c8 to
d533d11Compared533d11 to
f2cffa7CompareThis 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. |
FixesNativeScript/nativescript-dev-webpack#607
Fixes#10376
Closes/Supersedes angular/devkit#753