Fix path fragment inputs #229
Conversation
|
The issue with this PR is that resolveId isn't used exclusively for resolving module imports found in code. It's also used to resolve any modules specified in manualChunks. So the check for |
|
I a way, manual chunks start their own module graphs where the actual manual chunk that is created is the intersection between the graph created by the manual chunk entries and the graph created by the "normal" entry points. Somewhat confusing but allows for putting all modules in a package into the same manual chunk even when only deep imports are used. |
|
Maybe in the situation where the importer is |
|
@lukastaegert That's a good idea, I'll take a stab at implementing it. I'm curious: do you call a path like "foo/bar" an absolute path? I've been calling it a path fragment or an implicit relative path, but I'm no path wizard. |
|
I think there are places in the code where such a path is referred to as "absolute". I know that is definitely not the correct name! |
When resolving an import name that doesn't look like a relative or absolute path, first attempt to resolve the corresponding relative path before resolving the original import name.
bterlson
force-pushed
the
fix-path-fragment-inputs
branch
from
cf46938 to
a5ff1a9
Compare
|
I've implemented the two-pass lookup suggested by @lukastaegert above. I unified this somewhat with my previous PR #223 which was also implementing a two-pass lookup, so the logic is more clear now. I think this is ready for review! |
This PR addresses #228 by prefixing path fragments with
./before passing to node resolve. This makes some sense as node will not resolve modules by file path unless they start with/,./, or../. With this change, the new test passes.Unfortunately, this PR regresses the test
generates manual chunkswhich now throwsCould not resolve entry module (simple). I'm not sure what the cause of this is, but since I may not be back for a while, putting this PR up in case it helps anyone else. Feel free to close if it's not helpful.