swc
swc copied to clipboard
swc-project
Alternative package manager support for the module resolution
Describe the feature
Since the currently implemented plugin resolve algorithm relies on the node_modules structure, it doesn't work with alternative module linking approaches like ones from pnpm and Yarn Berry.
While directly pointing at the WASM binary is implemented as a temporary workaround, this should be covered with a more elegant and user-friendly approach.
Initially discussed in the Discord channel
Babel plugin or link to the feature description
No response
Additional context
No response
This is largely about module resolution we use in swc. It is not limited to plugin itself but somewhat overlaps to bundler, or any other features needs module resolution in some way.
Two main questions
- We'll support npm as first class citizen. What else / and how? there are some esoteric implementation like yarn's pnp.
- What / how to provide way to explicitly specify some resolution? We already support polymorphic behavior of plugin config itself (path vs. module name). But we need better.
We'll support npm as first class citizen. What else / and how? there are some esoteric implementation like yarn's pnp.
One really nice thing about yarn pnp is that there is one source of truth for how modules are resolved. Particularly with monorepo structures it can be really complicated if there are multiple things trying to resolve a module:
- Your IDE.
- Your bundler.
- Other tooling (type-checker, linting, etc).
One really nice thing about yarn pnp
I know good things about pnp and I'd like to use for some other places as well.
Main blocker in here is yarn's pnp resolution relies on its generated resolver in js, which swc's host cannot resolve by running it. This means it may requires to reimplement whole resolving logic by ourselves which I consider as heavy blocker to support.
for plugin:
I think a postInstall would work,
or maybe we can put it in bin in package.json and try to parse generated .sh file in node_modules/.bin.
for bundler:
I think it support pnpm since we follow soft link. but no idea for yarn pnp.
We do not have any work in the progress / do not have visible plan for this. This issue is filed for tracking purpose.
Main blocker in here is yarn's pnp resolution relies on its generated resolver in js, which swc's host cannot resolve by running it.
Yarn supports a JSON data file. Perhaps that might be an easier pnp map to integrate with? You don't need to run any JS.
The preferred approach IMO would be to expose a plugin API for module resolution. Yarn could then maintain their own plugin.
The doc I was referencing was https://yarnpkg.com/features/pnp#initializing-pnp which explicitly says it creates cjs. Where does those json spec exists?
Also it doesn't mean reducing lot of work. The only difference is port cjs resolution logic to rust, while json we need to still deal with all others like zipfs implementation.
Opening up module resolution is huge refactoring work, and it still requires yarn implements above logic. If that's the case, someone can directly upstream pr still. In short, the issue is amount of the work and resources we need compare to the active userbase we currently support who should use pnp.
It's opt-in. You have to set pnpEnableInlining to false to generate the json file: https://yarnpkg.com/configuration/yarnrc#pnpEnableInlining
The spec for .pnp.data.json is here: https://yarnpkg.com/advanced/pnp-spec.
In addition to Yarn itself, it's also been implemented in ESBuild v0.15.0.
I'm marking this as open for contributions. Anyone would like to provide support welcome to review PR, however we do not have enough bandwidth to try this by our own.