Skip to content
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

Determining path to a dependency within resolve plugin #3415

Open
paralin opened this issue Sep 29, 2023 · 6 comments
Open

Determining path to a dependency within resolve plugin #3415

paralin opened this issue Sep 29, 2023 · 6 comments

Comments

@paralin
Copy link

paralin commented Sep 29, 2023

How can I determine the path to the root directory of a npm package with esbuild based on an import? For example if I am resolving "import react" in a plugin, how can I determine that it's located at node_modules/react?

#3413 would have made this possible by resolving package.json and then getting the dirname from that. But since that isn't allowed due to the export rules in the nodejs specification, how can this be done?

@evanw
Copy link
Owner

evanw commented Sep 29, 2023

That's up to you really. It sounds like you have custom requirements so you might need something custom. For example, you could use a library such as https://github.com/browserify/resolve that I believe is supposed to give you lots of options for how packages are resolved as well as callbacks for various parts of the process.

@paralin
Copy link
Author

paralin commented Sep 29, 2023

@evanw I'm confused because this seems like duplication of concerns. If I apply the PR #3413 and then resolve package.json, esbuild finds the root of the module just fine. So why do we need a separate js-based resolve when esbuild is capable of doing it with a pure-Go approach?

@evanw
Copy link
Owner

evanw commented Sep 29, 2023

You never really said why you're trying to do what you're asking for, so I'm not exactly sure what to recommend. If you need something custom that can tweak various steps of the package resolution algorithm then esbuild's default package resolution algorithm may not be what you need. That's why I was recommending something more customizable.

You could always use esbuild's package resolution algorithm to resolve the entry point for the package, but as you have seen package authors are allowed to customize path resolution for anything within their package so that may still not give you want you want (e.g. the package author may have disabled the entry point, although that wouldn't result in a particularly useful package).

@paralin
Copy link
Author

paralin commented Sep 29, 2023

Okay, I'll provide more info. I'm trying to resolve the root directory of a package within node_modules because I'm working on a compiler tool that runs esbuild on third party dependencies to bundle them as external modules that are required through the "external" mechanism in esbuild.

At the moment I do everything in Go and was hoping to keep it that way. (Thanks to esbuild which is fantastic). However, I need the patch I showed in the PR to be able to locate the root directory of each node_modules package.

Since I'm already able to do this with esbuild within the OnResolve callback, I was hoping there would be some way to accomplish this properly with esbuild.

@evanw
Copy link
Owner

evanw commented Nov 19, 2023

FWIW a hack to use here that would likely work fine in the vast majority of cases without actually resolving the intermediate path to the package could be to resolve the entry point and then search for the last node_modules/[@optional-scope/]package-name segment in the path to get the path to the package.

@paralin
Copy link
Author

paralin commented Nov 19, 2023

@evanw while this might work in most cases, (I think even it would work with npm link? But does someone resolve the symlink there before the path is evaluated?), the solution of asking esbuild nicely which package.json it used to resolve the import is a lot more reliable (it seems) in the long run. I still wonder if there's some way that this could be allowed in the API, since it's such a minor change (to allow resolving package.json) and while it's not part of the spec, perhaps some alternative path to asking for this information is possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants