Import path completions don't include file extensions that are part of export wildcard globs

[vdegenne]

Demo Repo

https://github.com/ghost/myrepo

Which of the following problems are you reporting?

Something else more complicated which I'll explain in more detail

Demonstrate the defect described above with a code sample.

A video is worth a thousand words

screencast_2025-11-01_18-36-25.mp4

The .js part there is lost

Run tsc --showConfig and paste its output here

private project,
happens everywhere though.

Run tsc --traceResolution and paste its output here

private

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

private

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

private

Any other comments can go here

The issue appears both on vscode, and in nvim using mason/lsp/tsserver

[RyanCavanaugh]

We need a concrete way to repro this. It's entirely possible this is due to a configuration problem.

[vdegenne]

@RyanCavanaugh Can I make a repo and you guys workspace it? Would this work?

[RyanCavanaugh]

Yeah, if we can clone locally that's perfect

[vdegenne]

@RyanCavanaugh I made a repo: https://github.com/vdegenne/esm-paths-not-working

There are actually two issues that I wanted to report so I took the opportunity to include them both in the same repository, though they are really similar and can be debugged in the same manner.

I really hope this get resolved anytime soon. It's been quite a while now since this issue is around.

[RyanCavanaugh]

This is a correct error as @local/a has no . export in its export map. You can either write

import {} from '@local/a/foo.js';

or modify your package.json

{
	"name": "@local/a",
	"version": "1.0.0",
	"exports": {
		".": { // <- added
			"import": "./build/foo.js",
			"types": "./build/foo.d.ts"
		},
		"./glob/path/*.js": {
			"import": "./build/*.js",
			"types": "./build/*.d.ts"
		},
		"./foo.js": {
			"import": "./build/foo.js",
			"types": "./build/foo.d.ts"
		}
	}
}

[vdegenne]

@RyanCavanaugh Thanks for your quick response.
However I've updated the repo with the modification you suggested, but the issue is still there.

Can you please look into it again, I'm 100% convinced this is an issue with nodenext. The problem has always been there and has never had proper attention.

edit: in the screenshot it should be foo.js bar.js, baz.js not just foo, bar, baz.

[RyanCavanaugh]

What is "the issue" exactly?

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[vdegenne]

What is "the issue" exactly?

Well there are 2 issues, but for keeping things formal and easier to manage, the complain in this conversation is about the globs not including the extension (E.G. bar instead of bar.js.).
It's really that easy.
I'm 100% confident this is a valid issue and it should be addressed in order to move forward in the nodenext area.

[RyanCavanaugh]

No, this is not a bug. I'm very confident because a) it's what node does and b) no one else is reporting this; if nodenext were fundamentally broken in the way you're describing, you certainly would not be the first person to ever mention it.

In packages/b, write a .mjs file:

import * as foo from "@local/a";

and run it, you'll get an error:

node:internal/modules/esm/resolve:314
  return new ERR_PACKAGE_PATH_NOT_EXPORTED(
         ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in D:\Throwaway\esm-paths-not-working\node_modules\@local\a\package.json imported from D:\Throwaway\esm-paths-not-working\packages\b\using-lib.mjs
    at exportsNotFound (node:internal/modules/esm/resolve:314:10)
    at packageExportsResolve (node:internal/modules/esm/resolve:661:9)
    at packageResolve (node:internal/modules/esm/resolve:774:12)
    at moduleResolve (node:internal/modules/esm/resolve:854:18)
    at defaultResolve (node:internal/modules/esm/resolve:984:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:780:12)
    at #cachedDefaultResolve (node:internal/modules/esm/loader:704:25)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:687:38)

Same if you write

import * as foo from "@local/a/foo";

produces

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './foo' is not defined by "exports" in D:\Throwaway\esm-paths-not-working\node_modules\@local\a\package.json imported from D:\Throwaway\esm-paths-not-working\packages\b\using-lib.mjs
    at exportsNotFound (node:internal/modules/esm/resolve:314:10)
    at packageExportsResolve (node:internal/modules/esm/resolve:661:9)

If you change it to include .js file extension, then it works:

import * as foo from "@local/a/foo.js";
console.log("I loaded successfully because that's what the export map said");

produces

I loaded successfully because that's what the export map said

[vdegenne]

@RyanCavanaugh I don't know if you realize you are actually showing me exemples of what I am actually reporting...

Your exemples just confirmed the issue I'm reporting is legit and valid.

If I accept the first suggestion in the screenshot exemple, it will resolve to

import ... from '@local/a/glob/path/bar';

right?
Is it correct?
According to your exemple: no this is not correct and should be

import ... from '@local/a/glob/path/bar.js';

because bar, baz, foo are js files caught by the glob wildcard, they are not directories.

(Also I don't mean to be rude but saying "it's not an issue because nobody's been reporting it" (when nodenext paths resolution have more than one issue and I'm literally reporting them) is a bit ironic..)