Module resolution: wildcard exports don't work without file extensions when `"moduleResolution": "bundler"`

[Scalahansolo]

Demo Repo

https://github.com/Scalahansolo/wild-card-exports

Which of the following problems are you reporting?

The module specifier resolves at runtime, but not at build time

Demonstrate the defect described above with a code sample.

With a shared library in the monorepo...

{
  "name": "@repo/library",
  "version": "1.0.0",
  "type": "module",
  "exports": {
    "./*": "./src/*"
  }
}

I would expect to be able to import the files from this package like so...

import { greet } from "@repo/library/utils";
import { Component } from "@repo/library/component";

Run tsc --showConfig and paste its output here

{
    "compilerOptions": {
        "target": "es2024",
        "module": "preserve",
        "moduleResolution": "bundler",
        "strict": true,
        "skipLibCheck": true,
        "jsx": "react-jsx",
        "esModuleInterop": true,
        "allowSyntheticDefaultImports": true,
        "resolvePackageJsonExports": true,
        "resolvePackageJsonImports": true,
        "resolveJsonModule": true,
        "useDefineForClassFields": true,
        "noImplicitAny": true,
        "noImplicitThis": true,
        "strictNullChecks": true,
        "strictFunctionTypes": true,
        "strictBindCallApply": true,
        "strictPropertyInitialization": true,
        "strictBuiltinIteratorReturn": true,
        "alwaysStrict": true,
        "useUnknownInCatchVariables": true
    },
    "files": [
        "./src/index.ts"
    ],
    "include": [
        "src"
    ]
}

Run tsc --traceResolution and paste its output here

src/index.ts:1:23 - error TS2307: Cannot find module '@repo/library/utils' or its corresponding type declarations.

1 import { greet } from "@repo/library/utils";
                        ~~~~~~~~~~~~~~~~~~~~~

src/index.ts:2:27 - error TS2307: Cannot find module '@repo/library/component' or its corresponding type declarations.

2 import { Component } from "@repo/library/component";
                            ~~~~~~~~~~~~~~~~~~~~~~~~~


Found 2 errors in the same file, starting at: src/index.ts:1

Paste the package.json of the importing module, if it exists

{
  "name": "@repo/app",
  "version": "1.0.0",
  "type": "module",
  "scripts": {
    "tsc": "tsc"
  },
  "dependencies": {
    "@repo/library": "*",
    "@types/react": "19.2.7",
    "react": "19.2.3",
    "typescript": "5.9.3"
  }
}

Paste the package.json of the target module, if it exists

{
  "name": "@repo/library",
  "version": "1.0.0",
  "type": "module",
  "exports": {
    "./*": "./src/*"
  }
}

Any other comments can go here

Have a nice day!

[Scalahansolo]

Based on a looking through the Node spec Claude also seemed to think this is a bug in Typescript. https://claude.ai/share/ffab0a9c-27e5-408b-b2ca-edfbb8b7dd15

[Andarist]

Node.js (and bundlers) then apply their own extension resolution rules to find ./src/utils.ts or ./src/utils.js

package.json#exports were specifically designed to make extensions explicit. Extensionless resolution (and directory resolution that allows ./dir to resolve to ./dir/index.js) has real performance implications at scale as the tooling has to probe multiple locations to learn what file should be loaded.

That said, bundler is a mode with more relaxed rules and some bundlers, kinda incorrectly, might actually allow this. I think this was a conscious decision by Andrew Branch (@andrewbranch) to not support this and it's not a bug of omission. Time flies though and perhaps there is some room to still discuss if allowing this is a good idea or not. That's not up to me though 😉

[Scalahansolo]

Yeah, I've been discussing this with Boshen. Currently vite handles this type of export setup and is able to build properly.

Also worth mentioning that currently Typescript handles the following exports well enough but I imagine this has the same type of performance implication as having to probe for extensions?

"./*": [
    "./src/*.ts",
    "./src/*.tsx"
  ]

This type of wildcard export doesn't play well with vite at least. I guess the question here is that for bundler... or should I be pushing on the void zero team to support fallbacks like in this example?

[Andarist]

Also worth mentioning that currently Typescript handles the following exports well enough but I imagine this has the same type of performance implication as having to probe for extensions?

Kinda, but it's up to the library author here to introduce that cost. The penalty is not "mandatory". IIRC, array fallbacks are also kinda deprecated.

[Scalahansolo]

Fwiw, and the for the sake of this conversation, I'm coming at this from the perspective of using shared packages inside of a large mono repo. The considerations aren't that different from proper libraries. The motivations is just a bit different is all.

If the answer to this line of questions really is "Even for moduleResolution: bundler, we don't want to support extension-less wildcards AND array fallbacks are in a pseudo deprecated state, to be properly deprecated later", then at the very least that gives the community at large some clarity about how to proceed?

If the above were true, it would alter the path I would be trying to take in setting up mono repos.

[andrewbranch]

I remember talking to Boshen and others about this years ago, and I thought we had broad consensus that it would be really great for the ecosystem if there was literally one thing that other tools could adopt from Node.js without making subtle modifications that will proliferate more cross-compatibility bugs across npm that nobody will understand. Extremely disappointed to hear that’s no longer the case.

should I be pushing on the void zero team to support fallbacks like in this example?

No. I'm not happy that we support array fallbacks; it's a bug like #50762. You should use exports according to the Node.js spec, flawed as it is. There is, by design, no standard solution for wildcards that could resolve to a .ts or .tsx file, whichever happens to exist. But maybe a compromise could be

"./*.tsx": "./src/*.tsx",
"./*": "./src/*.ts"

or even

"./tsx/*": "./src/*.tsx",
"./*": "./src/*.ts"

if you really hate writing dots.

[Scalahansolo]

Ultimately, I just want to understand how things should work and try to align around where the eco system wants to move. I don't mind that compromise (I'm inclined to say the first option makes more sense). But again, having a bunch of different ways to do this is the ultimate issue.

Based on this conversation it feels like the "right" answer is to do one of two things.

• Either avoid wild card exports completely, and just set up packages to have very targeted exports.
• Allow for wild cards to exist, but make it clear to people that your package should just centralize around a single extension. I.e. Don't mix .ts and .tsx

Both have their draw backs in various scenarios.

[Scalahansolo]

To add some additional context to the conversation here, one of the reasons this ultimately felt like a but was that the imports key in package.json files don't seem to require extensions. The below config works just fine.

There is also some recent movement in the ecosystem (including typescript) related to subpath imports that seems at least partially related to this.

• Node JS PR
• Typescript PR related to subpath imports

In these items, all the example that are being shown off are extensionless, so it felt odd that exports require it.

[andrewbranch]

If imports is extension searching, I'm pretty sure that's a bug on our part.

I’m not a big fan of blanket wildcard exports across an entire library; it feels like your public API and the way you want to organize your implementation across files are different concerns. But I think they make sense in certain cases in targeted subdirectories.

As for mixing .ts and .tsx, it's a little weird because it's only a problem since we're talking about writing exports that point to uncompiled TS files instead of JS, something you wouldn't do in a published library. If you were publishing, they would all be .js files. And if you were using project references, you could actually write your exports relative to your output files like "./*": "./dist/*.js" and we would transparently map that back to the input file in src, where we would search both for .ts and .tsx files. It's only this particular setup that has an apparent ambiguity. Looking at the code, I actually think you can technically get away with removing the "./src/*.tsx" entry from that array, and I'm pretty sure we silently allow for matching a .tsx file with the "./src/*.ts" pattern.

Avoid array fallbacks, avoid #50762, and otherwise what TS lets you resolve is fine to rely on.

[Scalahansolo]

If imports is extension searching, I'm pretty sure that's a bug on our part.

I had a rogue path mapping still alive. Yeah the imports field requires extensions as well.

For published libraries, I agree with everything your saying 100%.

The use case Im specifically working with is a large monorepo where the packages are all purely internal to the code base. The bundler (in our case, vite rolldown) is doing the bundling for all of our applications, so we have no need to actually transpile our code with typescript directly.

Looking at the code, I actually think you can technically get away with removing the "./src/.tsx" entry from that array, and I'm pretty sure we silently allow for matching a .tsx file with the "./src/.ts" pattern.

This is definitely not the case. Get tsc issues with not being able to find any file that ends in .tsx