Repository navigation
Turbopack: report unknown module types at the import - #100534
lukesandberg wants to merge 1 commit into
Conversation
Failing test suitesCommit: 3f8a865 | About building and testing Next.js
Expand output● transpile-packages-typescript-foreign › without transpilePackages › should fail
Expand output● transpile-packages-typescript-foreign › without transpilePackages › should fail
Expand output● HMR - Error Recovery, nextConfig: {"basePath":"/docs","assetPrefix":"/asset-prefix"} › should recover after webpack parse error in an imported file
Expand output● HMR - Error Recovery, nextConfig: {"basePath":"/docs","assetPrefix":""} › should recover after webpack parse error in an imported file
Expand output● HMR - Error Recovery, nextConfig: {"basePath":"","assetPrefix":""} › should recover after webpack parse error in an imported file
Expand output● HMR - Error Recovery, nextConfig: {"basePath":"","assetPrefix":"/asset-prefix"} › should recover after webpack parse error in an imported file
Expand output● transpile-packages-typescript-foreign › without transpilePackages › should fail
Expand output● transpile-packages-typescript-foreign › without transpilePackages › should fail |
395e750 to
59abb71
Compare
A file that no module type applies to has no module in the module graph, so its "Unknown module type" error had neither a location nor an import trace, and didn't say which import pulled the file in. `handle_resolve_error` now keeps the location of the import with such a file in the resolve result, and the file is reported there when it turns out to be needed as a module. A file that is only resolved, e.g. traced, is still not reported. Files resolved without a known import location are reported without a location, as before.
59abb71 to
3f8a865
Compare
Summary
A file that no module type applies to (e.g. a
.txtwithout a loader) never becomes a module, so it has no place in the module graph. Its "Unknown module type" error had no location and no import trace, and did not say which import pulled the file in. This was worst for requests the user did not write by hand, like dynamicrequire(./dir/${x})requests, globs and contexts.handle_resolve_errornow records the location of the import on such files in the resolve result. When a file turns out to be needed as a module, it is reported at that import, naming the file. Files that are only resolved and never needed as modules (e.g. traced externals likesharp'srequire.resolveof a.dylib) are still not reported, as before. Files resolved without a known import location are reported without one, as before.This also replaces the custom "import.meta.glob() matched a file that has no module type" issue, since the general one now points at the call.
Stacked on #100526.
Verification
unknown-module-typeandrequire-context-unknown-type; updated issue snapshots fordynamic-unrelatedandimport-meta-glob-unknown-type.test/production/app-dir/import-meta-glob-unknown-type(the code frame is syntax highlighted, so the test now strips ANSI codes).test/e2e/app-dir/next-image(start, Turbopack): no new errors for traced files.