Repository navigation
Consult package.json contents when creating tsconfig.json under tsc --init to determine better defaults #51207
Description
Bug Report
🔎 Search Terms
tsc init module commonjs
🕗 Version & Regression Information
4.9.0-dev.20221017
⏯ Playground Link
n/a
💻 Code
package.json
{
"name": "asdf",
"version": "1.0.0",
"description": "",
"author": "",
"license": "ISC",
"type": "module",
"devDependencies": {
"typescript": "^4.9.0-dev.20221017"
}
}🙁 Actual behavior
> npx tsc --init
Created a new tsconfig.json with:
TS
target: es2016
module: commonjs
strict: true
esModuleInterop: true
skipLibCheck: true
forceConsistentCasingInFileNames: true
You can learn more at https://aka.ms/tsconfig
🙂 Expected behavior
it should check the package.json to determine that module should be nodenext or something
Activity
[-]`tsc --init` sets `module` to `"commonjs"` when `type` is `"module"` in `package.json`[/-][+]Consult `package.json` contents when creating `tsconfig.json` under `tsc --init` to determine better defaults[/+]DetachHead commentedon Apr 14, 2023
moduleResolutionshould also default tonodenextornode16when"type": "module"is inpackage.json.also, maybe it would be better to not even include these options when running
tsc --initand instead just infer the default values frompackage.jsonwhen they are not present intsconfig.jsonakwodkiewicz commentedon Nov 22, 2023
I would argue that
module+moduleResolutionshould be set tonodenext+nodenext/node16+node16for both CommonJS and ES Module projects, not only for the latter.After all,
node16+node16are the settings that allows you to correctly transpile dynamicimport().The current default of
commonjs+nodedoes not let you use ESM packages inside a CommonJS project, even if a dynamic import was used, it fails quietly (#45125).