ModuleResolution Node16/NodeNext fails without extension starting on 5.5.0-dev.20240413 about typescript HOT 8 CLOSED

https://stackblitz.com/~/github.com/Noriller/ts-issue-58214

I hope this one helps.

In the test.d.ts with the current typescript@next and same jsconfig (its a legacy project, using mostly jsdocs, but with the problem in a d.ts file)

If changing ts version with:

npm i -D [email protected]

then both work

from typescript.

We need a complete repro here; the package.json of @some/package, its contents, the importing package, and the tsconfig for the importing file all matter

from typescript.

This bisects to #57896. @andrewbranch

(I'm not an expert, but it seems strange that you'd need an extension when the d.ts file is effectively CJS, importing another CJS file, but importing via a JS file is already funky.)

from typescript.

Guessing I accidentally made ImportTypes look like an ESM-mode source location, when they were previously kept CJS-mode for backward compatibility reasons. Will take a look. Thanks!

from typescript.

Your jsconfig.json is invalid:

Option 'module' must be set to 'Node16' when option 'moduleResolution' is set to 'Node16'

module is defaulting to es2015 because of target, which is causing everything to resolve under ESM rules (since everything will emit as ESM). I’d argue this is probably more logically consistent than what we used to do, where the module resolution implementation made a lot more assumptions about module format and emit.

I guess we could consider making --moduleResolution node16 imply --module node16 instead of issuing an error, but I think we did the error on purpose so that people would notice we were making a breaking change when we started requiring these options be used together in #54567.

from typescript.

That works for the import, but adding "module = node16" breaks for .js files "exporting" jsdoc types.

I've updated the example with that case (link again)

When a .js file don't import/export anything (in this one case it's still using module.exports) then the declared types can be used globally as if they were declared in a d.ts file.

Using "module = commonjs" apparently fixes the problem I had earlier while keeping other uses working, but it still gives an error in the jsconfig file.

I also had other projects that did have modules and that we do have types declared in a separate file.

BTW, about the error, since package.json also has a "module" option, maybe too much, but adding a "in this config file" to that type of error might make it clearer.

As for the case of exporting jsdoc types for global use, I'm not sure what should be the intended behavior.

from typescript.

You can set "moduleDetection": "legacy"

from typescript.

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

from typescript.