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

Yarn PnP #460

Open
arcanis opened this issue Mar 11, 2025 · 2 comments
Open

Yarn PnP #460

arcanis opened this issue Mar 11, 2025 · 2 comments

Comments

@arcanis
Copy link

arcanis commented Mar 11, 2025

Yarn PnP is an alternative resolution strategy originally created for Yarn, and it’s also available in pnpm. Its key difference is a static resolution map: Yarn generates a file that tells Node.js and bundlers exactly where packages live on disk based on name and version. This is faster (no filesystem calls), and more stable (no ghost dependencies).

Most JavaScript libraries work with Yarn PnP out of the box. Over the past seven years, we’ve collaborated with various resolution libraries to build native PnP support. As a result, tools like Webpack, Rollup, Esbuild, Rspack, and even TypeScript now support PnP—albeit with one caveat.

Adding Yarn PnP support to TypeScript has proven challenging. The Yarn team has maintained a patch that we automatically apply to TypeScript installations. While this has worked so far, it’s not ideal: it introduces untested paths, requires regular updates, and doesn’t work for native code. The latter is especially worrisome, because it’s unclear how Yarn PnP and typescript-go will coexist. It would be unfortunate if developers had to abandon one technology to use the other. I've personally been hoping for a project like typescript-go for a long time now. I really want us to be able to use it!

Given my team's history of maintaining a PnP codepath over an extended period of time, we’d like to propose adding native PnP support to the experimental TypeScript codebase, and to help maintaining it in the future. We would do so only if we can ensure solid implementation quality and address any security concerns (i.e., avoid dynamic code execution). We have relevant experience, as both Esbuild (Go) and Rspack (Rust) use a static-data approach rather than relying on the Node.js loader API.

Ref: microsoft/TypeScript#28289
Ref: microsoft/TypeScript#35206

@goloveychuk
Copy link

@jakebailey
Copy link
Member

I said this on bluesky, but I think the prospect of doing this is technically better in the Go version than TS, just since Go has zip support and a FS wrapper for it (which will plug nicely into the VFS code we have here). I don't want to make promises, but I think it'd be interesting to explore this.

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

3 participants