tsdown rewrites externalized package subpath imports to internal resolved files

[egilsster]

Reproduction link or steps

NOTE: done by help of GPT 5.4

The difference between builds can be seen here https://github.com/egilsster/tsdown-mui-subpath-rewrite – it's using two different versions to build it, so it's easy to compare the two outputs. 0.21.4 is working quite well for us, and I suspect this commit is the culprit c51502b.

Hopefully this showcases the change, and if its an intended changes let me know. I tried to do a reproduction that didnt include Jest, because that was the source of pain after this update (some of our internal projects havent had time to switch to Vitest where this issue is not seen, due to proper ESM support).

An example failure of a test case in Jest was like this:

  ● Test suite failed to run

    Jest encountered an unexpected token

    Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.

    Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

    By default "node_modules" folder is ignored by transformers.

    Here's what you can do:
     • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
     • If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation, specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/configuration
    For information about custom transformations, see:
    https://jestjs.io/docs/code-transformation

    Details:

    /home/runner/work/my-project/node_modules/@material-ui/core/esm/Grid/index.js:1
    export { default } from './Grid';
    ^^^^^^

    SyntaxError: Unexpected token 'export'

What is expected?

When a dependency is externalized, the emitted import specifier should remain the original package subpath import:

import Grid from "@material-ui/core/Grid";
import makeStyles from "@material-ui/core/styles/makeStyles";
export { Grid, makeStyles };

In other words, externalization should not rewrite package subpaths to internal resolved files from inside node_modules.

I'd expect subpaths to be preserved and not rewritten to the esm variant. We do configure esm as target, but have the material v4 and mui v5 packages and their friends in neverBundle since consuming projects provide them.

What is actually happening?

With tsdown@0.21.4, the emitted output is:

import Grid from "@material-ui/core/Grid";
import makeStyles from "@material-ui/core/styles/makeStyles";
export { Grid, makeStyles };

With tsdown@0.21.7, the emitted output becomes:

import Grid from "@material-ui/core/esm/Grid/index.js";
import makeStyles from "@material-ui/core/styles/makeStyles.js";
export { Grid, makeStyles };

So the dependency is still externalized, but the public specifier is rewritten to an internal resolved path.

Any additional comments?

This appears related to:

• c51502beb4d2bf482eb01c7e4611efad0ef6ac8c
• fix(deps): resolve subpath extensions for packages without exports field

The regression matters because it changes consumer runtime behavior, not just bundle text.

For MUI v4 specifically:

• @material-ui/core/Grid is consumer-safe in CommonJS-oriented tooling
• @material-ui/core/esm/Grid/index.js points directly at ESM under node_modules

That breaks downstream environments that intentionally do not transform node_modules, including common Jest setups.

The repro isolates the problem without involving Jest so the bug report is specifically about emitted external specifier rewriting.