ts-node not supporting Yarn's pnp mode

[luxalpa]

Search Terms

yarn pnp webpack

Expected Behavior

Expected ts-node / webpack to simply work with pnp. Unfortunately not the case.

Actual Behavior

It is unable to find any modules referenced in my webpack.config.ts

Steps to reproduce the problem

create a typescript file, such as for example: import * as path from path; console.log(path), use Yarn v2's pnp as nodeLinker, create an empty tsconfig.json (can also be the tsc --init version or really any tsconfig) try to run ts-node on this program.

Minimal reproduction

https://github.com/luxalpa/ts-node-bug

Specifications

• ts-node version: 10.2.1
• node version: 12.22.5
• TypeScript version: 4.4.2
• tsconfig.json:

{}

• Operating system and version: Ubuntu 20.04

[cspotcode]

yarn pnp makes some very aggressive changes to the node environment, even modifying typescript itself. What changes do you think need to happen in yarn's PnP or in ts-node to support this?

[luxalpa]

I am not very familiar with PnP or with the inner workings of ts-node's module resolution, but on this yarn page they are saying this:

Are you a library author trying to make your library compatible with the Plug'n'Play installation strategy? Do you want to use the PnP API for something awesome? If the answer to any of these questions is yes, make sure to visit the PnP API page after reading the introduction!

[cspotcode]

Here are some pointers to kick-start your investigation:

The error you're seeing is coming from TypeScript's module resolver within TypeScript's typechecker, not node's module resolver. (EDIT this erroneously said "yarn's module resolver", but it should be "node") yarn needs to monkey-patch typescript to add PnP support to TypeScript's module resolver. In this case, when yarn's docs talk to a "library author", it is directed at the TypeScript team. However, the TypeScript team has chosen not not merge yarn PnP support, which necessitates yarn's monkey-patching.

We wrap TypeScript's module resolver to reclassify modules as internal/external, but mapping from module specifiers to absolute paths is still happening via TypeScript's API, so is handled by TypeScript with yarn's patches.

ts-node/src/resolver-functions.ts

Lines 92 to 99 in aaf6052

	const { resolvedModule } = ts.resolveModuleName(
	moduleName,
	containingFile,
	config.options,
	serviceHost,
	moduleResolutionCache,
	redirectedReference
	);

This could be a yarn bug, or could be a ts-node bug. It is unlikely that ts-node needs to use the PnP API directly, since we delegate all resolutions to either Typescript's or node's resolution APIs, and both of those APIs are being monkey-patched by yarn PnP.

[cspotcode]

This repro works:
https://github.com/TypeStrong/ts-node-repros/tree/yarn3
https://github.com/TypeStrong/ts-node-repros/runs/3500140971

[luxalpa]

Thanks a lot! Seems like they must have resolved (no pun intended) this issue in 3.1.0.

[merceyz]

See yarnpkg/berry#3350