Module resolution using nodenext and a wildcard in package.json exports

[mikearnaldi]

Bug Report

🔎 Search Terms

Nodenext wildcard, type cannot be named

🕗 Version & Regression Information

The bug only appears when using nodenext for module resolution

⏯ Playground Link

Cloneable repo: https://github.com/geoffreytools/effect-test-tsc

💻 Code

import { TaggedClass } from '@effect/data/Data';
// import '@effect/data/Equal';

export class Foo extends TaggedClass('Foo')<{}> {}

🙁 Actual behavior

The inferred type of 'Foo' cannot be named without a reference to '../node_modules/@effect/data/Equal'. This is likely not portable. A type annotation is necessary.

🙂 Expected behavior

To compile correctly, without using nodenext it works fine and the same issue doesn't apply to other transitive imports such as Hash that are identically exported. All goes away the very moment there is either an explicit import of Equal or when adding to the library package.json the following:

{
  "exports": {
    "./Equal": {
      "import": {
        "types": "./Equal.d.ts",
        "default": "./mjs/Equal.mjs"
      }
    }
  }
}

Note that the library uses a wildcard ./* as each import map to a file and this is perfectly resolvable by node

[datner]

This impacts all multi-module/multi-entry modules.. Can someone take a look at this? it's really tedious trying to build in esm with this bug. This bug appears with a module self-import as well

import Foo from "app/Foo" // <-- types broken with `/*` exports

[andrewbranch]

I think https://github.com/microsoft/TypeScript/issues/56107 was a duplicate of this—see my analysis there.

This impacts all multi-module/multi-entry modules.

56107 was specific to a re-export pattern used by Effect; I haven’t seen other libraries affected by this. @datner, you may have been running into something else entirely. If anyone is having issues with this outside of Effect, please provide a repro so we can see if there’s something different going on.

[mikearnaldi]

I think #56107 was a duplicate of this—see my analysis there.

This impacts all multi-module/multi-entry modules.

56107 was specific to a re-export pattern used by Effect; I haven’t seen other libraries affected by this. @datner, you may have been running into something else entirely. If anyone is having issues with this outside of Effect, please provide a repro so we can see if there’s something different going on.

What's specific to Effect here? we are just re-exporting a module