René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Transpile TypeScript code inside `node_modules`.","articleBody":"### What is the problem this feature will solve?\n\n---\n\nI **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.\n\n---\n\nWith the introduction of `--experimental-strip-types` and `--experimental-transform-types`, it is now feasible to run TypeScript code directly without a separate build step.\n\nHowever, 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:\n\n```mermaid\ngraph TD\n  libA --\u003e server\n  libB --\u003e server\n  libC --\u003e server\n  libD --\u003e libB\n```\n\nTools 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`.\n\nThe 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.\n\nThis 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.\n\nThis 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.\n\nBun 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.\n\n\u003cbr /\u003e\n\n### What is the feature you are proposing to solve the problem?\n\nI'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.\n\n\u003cbr /\u003e\n\n### What alternatives have you considered?\n\nSome options have come to mind:\n\n1. Transpile all packages in `node_modules` that have `\"private\": true`. This ensures those packages did not come from a public registry.\n2. Add a flag like `--transpile-packages=@mycompany/*` to explicitly opt into transforming specific scoped packages.\n3. Automatically transpile all symlinked packages.\n4. 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`.\n\nA 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.\n\nSince 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...\n","author":{"url":"https://github.com/arthurfiorette","@type":"Person","name":"arthurfiorette"},"datePublished":"2025-05-23T01:11:41.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":67},"url":"https://github.com/58429/node/issues/58429"}