-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pnp: esbuild@0.15.2
unable to resolve dependencies of virtual dependencies outside of the project directory
#2463
Comments
esbuild@0.15.2
unable to resolve dependencies of a virtual dependency outside of the project directoryesbuild@0.15.2
unable to resolve dependencies of virtual dependencies outside of the project directory
I assume I'm hitting this part of the specification:
I'm supposed to track which manifest a given chain of imports comes from? What if the same file is imported from two separate manifests? Is the file supposed to be duplicated at that point so that the imports can potentially resolve to different things? |
In Yarn each manifest has its own module cache, so in a bundler that would lead to the file being twice in the bundle. I however can't think of a case where bundling sources from multiple manifests would be needed - perhaps it'd be easier, at least for the first iteration, to just call FIND_MANIFEST once, on the entry point, and use it for everything? |
Ok, I can change it to a singleton. There can be multiple entry points though. I can try to pick an approach for what to do in that situation. |
If you keep track of all the manifests you've found then they keep track of it, you can then call
We throw an error in cases like that because we don't know which manifest to use. |
I'm not sure but I think this sounds like it could introduce non-determinism in the build because which manifest ends up being used for a given file would depend on what order the files were visited in. This might not matter for a deterministic traversal of the module graph but esbuild traverses the module graph in parallel so the order is non-deterministic. |
I actually had to change this to be based on the current working directory instead of the entry point. Entry points are arbitrary strings and can sometimes not be file system paths at all (which can still be handled by plugins). |
Describe the bug
In a Yarn PnP project with the cache located outside of the project directory
esbuild@0.15.2
is unable to resolve the dependencies of virtual dependencies.Verbose log
Ref yarnpkg/berry#4732
To Reproduce
The text was updated successfully, but these errors were encountered: