NodeNext resolution failed to resolve dual-package correctly

Bug Report

NodeNext resolution failed to resolve dual-package correctly

🔎 Search Terms

NodeNext

🕗 Version & Regression Information

• Never worked

💻 Code

https://github.com/Jack-Works/ts-nodenext-wrong-resolution-reproduction

where node_modules/testpkg/package.json is

{
    "name": "testpkg",
    "exports": {
      ".": {
        "types": "./dist/type.d.ts",
        "require": "./dist/common.cjs",
        "import": "./dist/module.mjs"
      }
    }
  }

TypeScript should resolve type.d.ts in dual mode instead of CommonJS synthetic export.

🙁 Actual behavior

src/index.ts:2:1 - error TS2349: This expression is not callable.
  Type 'typeof import("testpkg/dist/type")' has no call signatures.

🙂 Expected behavior

No error

[olivier-martin-sf]

I am one of the maintainers of a “dual-package” and after reading this thread I have some questions related to the thread comments:

1. Is that correct that we should have one type declaration per file?
2. Should the type declarations uses the matching import/export semantics for the module system they are matching? (export for .d.mjs and module.exports for .d.cjs)
3. Does TypeScript will assume that a file ending with .d.ts is going to be an ESM if the type property is set to module in the package manifest?

More detailed below:

The package in question is declared as ES Module (the type property is set to module in the package manifest file). The package doesn’t have main entry points per se and is structured as follows:

├── dist/
    ├── foo/
        ├── someFile.cjs  # Common JS
        ├── someFile.d.ts # Type declaration  
        ├── someFile.js   # ESM

In this case, both the CJS and the ESM implementation expose the exact same API (actually the CJS implementation is transpiled from the ESM one via Rollup inside a compiler).

That’s how the exports look like for each implementation:

# someFile.js (ESM)
export default class C {}

# someFile.cjs (CJS)
class C {}
module.exports = C;

That’s how the type declaration looks like:

export default class C {}

And that’s how we configured the exports map in the package manifest:

"./*": {
    "types": "./dist/*.d.ts",
    "import": "./dist/*.js",
    "require": "./dist/*.cjs"
}

As soon as TS 4.8 has been released I tried to switch moduleResolution to NodeNext but it seems like I am hitting issues due to the fact that I am only using one declaration file if my understanding is correct. So basically, the format of my export map is wrong and I should opt for something close to what @DanielRosenwasser suggested.

I am also asking as the type declaration is being generated from our compiler and I will have to think about how we can generate one for CJS if we have to.

For instance, while trying to use the package in a project that uses CommonJS I am getting the following error from tsserver:

The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require' (ts1479)

Thanks in advance for your input.

[olivier-martin-sf]

That makes sense, thanks a lot for all the very useful information, I can see what I should be doing now!