Support type stripping in `node_modules`

[daquinoaldo]

What is the problem this feature will solve?

The ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING arises if you import a TypeScript file from another package. I understood this is to discourage having TypeScript-only packages. However, this also applies to private packages, where the organization decides whether a TS-only ecosystem fits for them. This is particularly annoying in monorepos, where imports are local, because it forces you to build the changed package before using it instead of changes just propagating naturally.

What is the feature you are proposing to solve the problem?

We could have an opt-in flag, environment variable, or package.json field that enables type stripping in node_modules. In this way, we keep discouraging TypeScript-only public packages, while allowing their usage in contexts where it makes sense.

What alternatives have you considered?

• pnpm Workspaces: In a monorepo, pnpm symlinks local packages, so development works fine. But when building an artifact (like a container image), pnpm prune copies local packages into node_modules, forcing you to copy the entire monorepo—which increases the artifact size.

• Turbo.build: Turbo lets you selectively copy only the necessary packages, avoiding the need to hardcode local packages in node_modules. The trade-off is that it introduces extra tooling and only works in monorepos; using local packages from cloned repositories still poses challenges (TS in development vs. JS in builds).

• File Watcher: A file watcher can rebuild changed dependencies and restart the server on file changes. However, this requires complex logic for monitoring files and managing dependencies.

[aduh95]

You can use a loader/module hook to workaround that. /cc @JakobJingleheimer

[JakobJingleheimer]

However, this also applies to private packages, where the organization decides whether a TS-only ecosystem fits for them. This is particularly annoying in monorepos, where imports are local, because it forces you to build the changed package before using it instead of changes just propagating naturally.

I believe this was specifically addressed, the package just needs "private": true to be set in its package.json.

You can use a loader/module hook to workaround that. /cc @JakobJingleheimer

Yes, you can use a loader like @nodejs-loaders/tsx. It's pretty trivial to set up 🙂

[marco-ippolito]

I think a flag to enable it would be reasonable

[ljharb]

For private true only packages, this seems fine to me; bit i don’t think node should ever provide anything that directly allows stripping types from published packages (not counting the tools so a loader can be easily built)

[marco-ippolito]

For private true only packages, this seems fine to me; bit i don’t think node should ever provide anything that directly allows stripping types from published packages (not counting the tools so a loader can be easily built)

I created a PR that read the package.json private property. But private apparently does not allow publishing at all

[ljharb]

Correct, that’s why it’s a viable escape hatch - because nothing can ever be published with private true, so the only way to have one of those in node_modules is if it’s bundled or linked in.

[aduh95]

Correct, that’s why it’s a viable escape hatch - because nothing can ever be published with private true

… on the public registry of npm, I’m not sure it makes sense to rely on it and assume it’s always going to be the case

[ljharb]

Certainly an unknown npm client, or an unknown private registry, could violate that rule (all known ones comply with it afaik), but the concern is package ecosystem leakage, and anything in those buckets isn't part of the package ecosystem.

[aduh95]

Node.js doesn't read the private property at all atm IIRC, it would feel a bit too magical to start now, I'd much prefer a flag – or even keep loaders as the only way to get this to work, the loader itself can choose to read the private field or not

[marco-ippolito]

Id create a flag and keep it opt in forever.

[ljharb]

As long as the flag didn't work in NODE_OPTIONS or any committable config file, that'd be fine - otherwise, it would still cause ecosystem leakage since package authors who want to ship TS directly will just tell people to commit that config somewhere.