refactor(@ngtools/webpack): use webpack resolver plugin for path mapping

[clydin]

Fixes NativeScript/nativescript-dev-webpack#607
Fixes #10376

Closes/Supersedes angular/devkit#753

[hansl]

That's a huge change just before release. I'd rather just revert the original buggy PR and investigate for 6.2.

[hansl]

What's going on with these paths? It looks like breaking backward compatibility.

[clydin]

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]

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.

[hansl]

So we give up on TypeScript resolution, which fixed a load of issues and supports tsconfig's path mapping. See #7473

[hansl]

I'm mostly curious of the two following assumptions in this PR:

1. we implement TypeScript's resolution ourselves, without any bugs and edge cases, and
2. we rely on TypeScript never updating their resolution algorithm and configurations, otherwise this will likely break.

[hansl]

Another example is how we lose support for rootDirs, which I think we don't test for.

[clydin]

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).

[ngbot]

Hi @clydin! This PR has merge conflicts due to recent upstream merges.
Please help to unblock it by resolving these conflicts. Thanks!

[angular-automatic-lock-bot]

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.}