Add new moduleResolution option: `yarn-pnp`

Search Terms

yarn pnp plug’n’play plug

Suggestion

Yarn has released a new feature for using modules without having a node_modules directory present: plug’n’play. Some community tooling is available for customizing the TypeScript compilerHost so that it can use plug’n’play modules, but this does not work for users of tsc.

My suggestion is to add a new "moduleResolution": "yarnpnp" option.

Use Cases / Examples

I want to be able to use yarn plug-n-play in my typescript projects. My projects are typically yarn monorepos where common libraries are basic node packages using tsc for compilation. This would allow the basic projects to continue using tsc, but with an alternative module resolution scheme.

Some community tooling has been created here for augmenting the CompileHost with a slightly updated moduleResolution strategy, but using it in basic projects would probably require a forked tsc.

https://github.com/arcanis/ts-pnp

Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript / JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. new expression-level syntax)

[jeysal]

Sorry if this is kind of a “+1” comment, but it looks like there are already solutions proposed and this is in a state where all that’s needed is commitment from the TypeScript team. We’ve tried to use Yarn PnP in the Jest repo before and post migration from Flow to TypeScript, and this is currently the biggest blocker, the other somewhat big one being ESLint’s import rules. I think this is really essential to helping PnP gain traction, because it enables other large projects that depend on TypeScript for their type checking / build process to use PnP, helping it mature and become more visible as a practical alternative to node_modules 🚀

[arcanis]

For what it’s worth the PnP runtime is now decoupled into its own package, which should solve one of the main concerns the TS team had (they can now simply read the PnP data without executing any third-party code). I’d be more than happy to finally meet and discuss how to make this happen, but I don’t feel like the ball ever was in my camp.