webpack does not work with latest @ngtools/webpack 6.1.0-rc.1 #607
Comments
|
We need @ngtools/webpack pre-release version for 979f732#diff-8ddd9c5028c697888286c099d3390459 |
|
Issue might be related to angular/angular-cli@47f937e#diff-8357b25ceb65af854095a8bf4ee953d0 ? |
|
More specifically it seems we now have an issue with (at least) Seems webpack was able to correctly resolve module format previously when https://github.com/angular/angular-cli/blob/63389e5028a33ce57d1fb776c1c8bdbd6004324c/packages/ngtools/webpack/src/paths-plugin.ts#L168 did not happen (i.e. it worked with request.request equal to |
|
@manoldonev Can you confirm this works (or not) with |
|
Seems like it does. You just mentioned rolling back to beta, so I was concerned. |
|
@manoldonev I'd need some reproduction steps to properly identify this. I can revert the 2 commits that affected the file but I'd like to setup an integration test on our side to prevent this regression in the future. Could you give me instructions on how to get the error above? (edit: in case you need some context, I'm the lead on the Angular CLI project) |
|
@hansl 10x for chiming in. I am still trying to figure this on our end as well but in short -- we have a folder structure like https://github.com/NativeScript/NativeScript/tree/master/tns-core-modules/ui where the ui folder is not actually a module but https://github.com/NativeScript/NativeScript/blob/master/tns-core-modules/ui/package.json exists with NativeScript specific information. Subdirectories of ui e.g. ui/actionbar, ui/animation are proper modules with their respective package.json. Also, it happens that a stand alone https://github.com/NativeScript/NativeScript/blob/master/tns-core-modules/ui/utils.d.ts in the same ui folder. At some point while running webpack the paths plugin from @ngtools/webpack receives request to resolve "tns-core-modules/ui/utils" (as originalRequest), with the module resolver this produces I am working on eliminating such scenarios from our codebase but if you could check whether the package.json contained a "main" field (besides package.json existence) I think we would be good. |
|
Why not add a |
|
Normally Angular libraries sub-packages are supposed to follow the fESM format (e.g. https://github.com/angular/angular/blob/master/packages/core/testing/package.json) |
If there is a package.json we should also verify that it has a main or fesm field to see if webpack would actually resolve it properly. Otherwise use the JavaScript resolution. This is a temporary fix and still has obvious limitations and issues. Namely, this code is never run if there is only one path mapping, but that falls outside the scope of this fix. Also, some people might have valid packages but want to resolve to the JS file itself (which is what TypeScript does by default). These should be fixed with a refactoring of the path plugin. Fixes NativeScript/nativescript-dev-webpack#607
If there is a package.json we should also verify that it has a main or fesm field to see if webpack would actually resolve it properly. Otherwise use the JavaScript resolution. This is a temporary fix and still has obvious limitations and issues. Namely, this code is never run if there is only one path mapping, but that falls outside the scope of this fix. Also, some people might have valid packages but want to resolve to the JS file itself (which is what TypeScript does by default). These should be fixed with a refactoring of the path plugin. Fixes NativeScript/nativescript-dev-webpack#607
|
@hansl just for some context -- tns-core-modules is not strictly an Angular library (it powers both Angular, Vue, and JavaScript/TypeScript flavors of our NativeScript framework for native mobile cross-platform development). |
|
@hansl btw I do agree that we could improve our package.json usage and made some modifications across our codebase but I am currently stuck on a rather cryptic Angular compiler runtime error (if I use @ngtoos/webpack 6.1.0-rc.1: Again, these same modifications work if I use @ngtools/webpack 6.1.0-rc.0. |
If there is a package.json we should also verify that it has a main or fesm field to see if webpack would actually resolve it properly. Otherwise use the JavaScript resolution. This is a temporary fix and still has obvious limitations and issues. Namely, this code is never run if there is only one path mapping, but that falls outside the scope of this fix. Also, some people might have valid packages but want to resolve to the JS file itself (which is what TypeScript does by default). These should be fixed with a refactoring of the path plugin. Fixes NativeScript/nativescript-dev-webpack#607
If there is a package.json we should also verify that it has a main or fesm field to see if webpack would actually resolve it properly. Otherwise use the JavaScript resolution. This is a temporary fix and still has obvious limitations and issues. Namely, this code is never run if there is only one path mapping, but that falls outside the scope of this fix. Also, some people might have valid packages but want to resolve to the JS file itself (which is what TypeScript does by default). These should be fixed with a refactoring of the path plugin. Fixes NativeScript/nativescript-dev-webpack#607
|
@hansl I can confirm that we are working correctly with @ngtools/webpack 6.1.0-rc.2 Thank you very much for your responsiveness! |
We no longer need to hardcode @ngtools/webpack to 6.1.0-rc.0 as #607 is fixed with @ngtools/webpack 6.1.0-rc.2
|
On further testing it seems we still have a problem with rc.2 and the unmodified version of tns-core-modules (i.e. without NativeScript/NativeScript#6067) |
|
@hansl it is the scenario where we had some folders like https://github.com/NativeScript/NativeScript/tree/master/tns-core-modules/debugger that contained a bulk of d.ts files but only single d.ts (debugger.d.ts) was actually referenced in the folder package.json (that is valid on its own i.e. with "main" field). When there is a request for tns-core-modules/debugger/devtools-elements.d.ts for example because of the package.json the paths plugin will try to resolve it via tns-core-modules/debugger/debugger.d.ts (that does not know anything about the devtools elements). |
|
Current logic of paths plugin will only work with the refactored version of tns-core-modules i.e. https://github.com/NativeScript/NativeScript/tree/mdonev/refactor-submodules/tns-core-modules/debugger (submodules introduced) but we need backwards compatibility. |
|
@hansl Do you need this specific enhancement for the resolution fallback mechanism in @ngtools/webpack? Would it be possible to revert the change so we do not break backwards compatibility on our end? |
This is a workaround for the issue with `@ngtools/[email protected]`, described here: NativeScript/nativescript-dev-webpack#607 (comment)
We no longer need to hardcode @ngtools/webpack to 6.1.0-rc.0 as #607 is fixed with @ngtools/webpack 6.1.0-rc.2
…itly (#6079) This is a workaround for the issue with `@ngtools/[email protected]`, described here: NativeScript/nativescript-dev-webpack#607 (comment)
…itly (#6079) This is a workaround for the issue with `@ngtools/[email protected]`, described here: NativeScript/nativescript-dev-webpack#607 (comment)
We no longer need to hardcode @ngtools/webpack to 6.1.0-rc.0 as #607 is fixed with @ngtools/webpack 6.1.0-rc.2
* fix: require devtools-elements.js with the extension mentioned explicitly (#6079) This is a workaround for the issue with `@ngtools/[email protected]`, described here: NativeScript/nativescript-dev-webpack#607 (comment) * release: cut the 4.1.1 release * chore: Fix TS transpile error with 2.9 (#5906)
|
@manoldonev Hi, I released RC3 yesterday. Can you try it? It reverted the faulty PR entirely. |
|
Hey @hansl! I can confirm that updating to @ngtools/webpack 6.1.0-rc.3 fixes the issue. |
If there is a package.json we should also verify that it has a main or fesm field to see if webpack would actually resolve it properly. Otherwise use the JavaScript resolution. This is a temporary fix and still has obvious limitations and issues. Namely, this code is never run if there is only one path mapping, but that falls outside the scope of this fix. Also, some people might have valid packages but want to resolve to the JS file itself (which is what TypeScript does by default). These should be fixed with a refactoring of the path plugin. Fixes NativeScript/nativescript-dev-webpack#607
Webpack does not work with latest @ngtools/webpack 6.1.0-rc.1:
The text was updated successfully, but these errors were encountered: