Mechanism to specify input source location to find `package.json` instead of output source location when determining module format

[monsanto]

🔎 Search Terms

nodenext, ts2351, construct

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about "A default import of a commonjs module with a default in a esm file doesn't seem to be the default export of that module when module is node16 or nodenext".

⏯ Playground Link

N/A

💻 Code

git clone https://github.com/monsanto/typescript-nodenext-bug
cd typescript-nodenext-bug
npm install
npm run tsc

🙁 Actual behavior

foo/index.ts:6:5 - error TS2351: This expression is not constructable.
  Type 'typeof import("<dir>/typescript-nodenext-bug/.cache/foolib/class")' has no construct signatures.

6 new CBad();
      ~~~~


Found 1 error.

🙂 Expected behavior

It succeeds.

Additional information about the issue

• This issue requires a composite project, NodeNext, a package boundary, a default export, and a parent directory with a file package.{json, json5, yaml} without type: module.
  • Please note that import default inside foo's package boundary works.
  • One can delete the provided package.json after installing and run node_modules/typescript/bin/tsc --build tsconfig-base.json to test without package.json present.
  • One can see other package extensions trigger the bug by mv package.json package.yaml and pnpm run tsc.
• This is not a CommonJS project. It doesn't matter that there is a parent package.json without it. Node doesn't even read package.yaml.
  • This is from a real-world monorepo where there is a root pnpm package.json5 for cross-package scripts.

Cross-ref for #62200

[andrewbranch]

The issue is that your outDir, where you're emitting declaration files, is outside the scope of any package.json that says "type": "module". When you use project references, we remap references to external .ts files to their .d.ts equivalents. We don't look up or load the .ts at all (once we're past the point that we've checked timestamps to ensure the build is up to date). So when the foo project loads .cache/foolib/class.d.ts, that file looks like CommonJS—TypeScript always reasons about module resolution with respect to your output files, and even though you have emitDeclarationOnly on at the moment, the assumed output file here is .cache/foolib/class.js, which would be CommonJS.

There are other behaviors where TypeScript cares too much about your "output file" and not enough about your "input files" for a world where Node.js, Bun, and other runtimes run .ts files directly. I'm not sure if we have an issue tracking it, but we've talked about making improvements that make checking actually understand what input and output files are going to be used for in a given project setup. This would fall into that work. It's not a bug that can be patched before 6.0.

[monsanto]

Okay, I can workaround this.

[paigefletcher1282-code]

It might be useful to add this to the docs

…

On Mon, Mar 16, 2026, 1:55 PM Christopher Monsanto ***@***.***> wrote: *monsanto* left a comment (microsoft/TypeScript#63251) <#63251 (comment)> Okay, I can workaround this. — Reply to this email directly, view it on GitHub <#63251 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7BB4JR3RIMA6A7N5R4Z6KL4RA5XJAVCNFSM6AAAAACWR3MYF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRZGU2TCNBYGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>