Repository navigation
[5.5 beta] package.json "type" lookup in non-Node.js module is unexpected #58663
Description
Activity
- changed the title
[-][5.5 beta] The `moduleDetection` option is ignored[/-][+][5.5 beta] The `moduleDetection` option is ignored for `verbatimModuleSyntax` error[/+]on May 26, 2024 That option doesn't control anything to do with ESM versus CJS, it's controlling "module" (uses some form of exports, declarations are local) versus "script" (all globals, like a script tag).
This sounds similar (but not the same) as the 5.5 issue we hit of
*.tsES modules being emitted as CommonJS despite alltsconfigoptions conveying that input and output should all be ESM, e.g."module": "esnext".The root cause seems to be the intentional decision to respect
package.json's"type": "commonjs"so that it takes precedence overtsconfig, i.e. input and output will be assumed to be CJS if the source file is*.tsand there's no way intsconfigto stop this.In our case we have a build system that up to now intentionally ignored
package.jsonso this coupling was unwelcome, but hey, maybe we just have an odd use-case. Nicolò Ribaudo (@nicolo-ribaudo) what is your use-case for wanting this decoupling oftsconfigandpackage.jsonsemantics?I am using TypeScript only for type checking, and I'm using Babel to do all transpilation. My build system will transpile those files either to ESM or to CJS and put them in appropriate folders with their own
package.jsonfile that has the correctpackage.json#type.These restriction seem to be only necessary when TypeScript is emitting JS files, and even in that case they should be based on the
package.jsonrelative to the output files and not to the input files.In the new TS5.5 behavior, how would I have to update my tsconfig to keep being able to have the following, when not emitting JS files through tsc?
- ESM syntax in
.tsfiles export =in.ctsfilespackage.json#type: commonjsin the rootpackage.json#type: modulein the ESM dist folder
What I find surprising about this new behavior is that my
moduleoption is not set to one of the possiblenode*values, so I would expect it to not be affected by the Node.js-specificpackage.json#type.
EDIT: It seems I can just disable
verbatimModuleSyntax: true,module: ESNextand@ts-ignorethe errors about usingrequireas a variable name, I need to check if this affects anything else.EDIT2: That doesn't work because then TS errors on
import handleMessage = ...in.ctsfiles- ESM syntax in
I guess what I would like to have is an option to tell TS "I know what I'm doing about modules syntax, please don't error when you think you won't be able to emit it correctly", or an option to restore the previous behavior.
and even in that case they should be based on the
package.jsonrelative to the output files and not to the input files.IIRC this was actually tried. I don’t remember the exact reasoning but it turned out to not really be viable. See discussion at #54593 and other issues linked therein.
This sounds similar (but not the same) as the 5.5 issue we hit of
*.tsES modules being emitted as CommonJS despite alltsconfigoptions conveying that input and output should all be ESM, e.g."module": "esnext".Some more context here: #58587 (comment).
Our tooling does not emit a Node.js package, the build output won't contain apackage.json. So any inference made about the content of the.tsfiles based on thepackage.jsoncan cause us issues. In the past this was mostly limited to npm auto-complete suggestions appearing which won't be available in this particular runtime. However with 5.5 this now extends to causing build errors which can only be addressed by modifying thepackage.jsonwhich just so happens to be in a parent directory of the project.Why are folks using an explicit
"type": "commonjs"over omitting"type"? Preemptive performance optimization for--experimental-detect-module?Just because
type: commonjsand no type should have the same meaning, and in this case I prefer to be explicit.Does TS handle those two cases differently?
Reacted by Toni VillenaIt does now outside of
node16/nodenext."type": "commonjs"is a more explicit signal than no"type". If you’re not targeting Node.js, it might be reasonable to leave that field unset and have ESM files, since Bun and most bundlers have no issue with that. But if you set"type": "commonjs", we take that as a signal that you at least want compatibility with Node.js, so we will use that signal to resolve ambiguities and prevent you from emitting something that will totally break it.they should be based on the package.json relative to the output files and not to the input files
See #54546
Reacted by Nicolò Ribaudo and Ryan Cavanaugh- changed the title
[-][5.5 beta] The `moduleDetection` option is ignored for `verbatimModuleSyntax` error[/-][+][5.5 beta] package.json `"type"` lookup in non-Node.js `module` is unexpected[/+]on Jun 10, 2024 Nicolò Ribaudo (@nicolo-ribaudo) Ashley Claymore (@acutmore) could you try the build at #58825 and see if that addresses your issues? I think it should, but getting some definite feedback on real projects would be great since we’re so close to the final 5.5 release here.
Reacted by Rob Palmer
🔎 Search Terms
moduleDetection force legacy
🕗 Version & Regression Information
⏯ Playground Link
No response
💻 Code
package.json:
{ "name": "ts-test", "version": "1.0.0", "description": "", "type": "commonjs", "devDependencies": { "typescript": "^5.5.0-beta" } }tsconfig.json:
src/index.ts:
🙁 Actual behavior
🙂 Expected behavior
Given that I'm using
"moduleDetection": "force", that file is an ES module (regardless of whatpackage.json#typesays) and thus I shouldn't see that error. This was the behavior in 5.4.Additional information about the issue
No response