Transpile TypeScript code inside `node_modules`.

What is the problem this feature will solve?

I do not propose allowing transforms for all packages in node_modules. That would encourage publishing TypeScript directly to npm, which comes with significant downsides for the ecosystem.

With the introduction of --experimental-strip-types and --experimental-transform-types, it is now feasible to run TypeScript code directly without a separate build step.

However, in monorepo environments, this feature is limited by how Node.js currently handles node_modules resolution. In a typical monorepo setup, you might have a structure like:

graph TD
  libA --> server
  libB --> server
  libC --> server
  libD --> libB

Tools like pnpm (and similarly yarn and npm workspaces) install local packages via symlinks into the node_modules folder. For example, if server depends on libA, pnpm will symlink (or copy, depending on configuration) libA into server/node_modules/libA.

The issue is that Node.js currently does not apply --experimental-strip-types or --experimental-transform-types to anything inside a node_modules folder, even if it’s a symlink to a local workspace package.

This forces developers to pre-transpile any local dependencies, which essentially defeats the purpose of the feature in monorepos, where the server package often represents only a small percentage of the codebase compared to its locally installed dependencies.

This might introduce some complexity to the current implementation, since each package could have its own tsconfig.json with potentially different options. That said, I’m not deeply familiar with the internals of --experimental-strip-types and --experimental-transform-types, so this is just an assumption.

Bun and Deno come to mind as the major runtimes that support TypeScript out of the box. A study might be needed to determine how to handle tsconfig resolution when transpiling packages inside node_modules. Should it respect each subpackage's own tsconfig? Or should it transpile everything according to the server’s tsconfig? I’m also unsure what the best or most correct approach would be here.

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

I'm still unsure what the best decision would be here, as there are multiple ways to distinguish which folders inside node_modules come from local/owned packages and which do not. What about private registries? There's still a lot to decide.

What alternatives have you considered?

Some options have come to mind:

1. Transpile all packages in node_modules that have "private": true. This ensures those packages did not come from a public registry.
2. Add a flag like --transpile-packages=@mycompany/* to explicitly opt into transforming specific scoped packages.
3. Automatically transpile all symlinked packages.
4. Require each package that needs to be transpiled to include a field like "source": "./src/index.ts" or a custom flag such as "needsTranspilation": true.

A flag like the latter would be especially useful, as it would enable users to publish TypeScript packages to private or internal registries while still opting into transformation behavior.

Since this restriction was intentionally designed to prevent publishing uncompiled TypeScript to npm, perhaps a more consistent approach would be to only block transpilation for packages that clearly come from the public registry. Again, there's a lot to discuss here...

Empieza examinando cómo --experimental-strip-types y --experimental-transform-types tratan actualmente el código bajo node_modules, incluidos los paquetes de workspace enlazados simbólicamente. El issue deja explícitamente sin decidir la detección de paquetes, la resolución de tsconfig y el comportamiento de opt-in; para darlo por terminado se requiere una política acordada y una implementación correspondiente para los casos de paquetes elegidos.