Consult `package.json` contents when creating `tsconfig.json` under `tsc --init` to determine better defaults

[DetachHead]

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

[DetachHead]

moduleResolution should also default to nodenext or node16 when "type": "module" is in package.json.

also, maybe it would be better to not even include these options when running tsc --init and instead just infer the default values from package.json when they are not present in tsconfig.json

[akwodkiewicz]

I would argue that module+moduleResolution should be set to nodenext+nodenext/node16+node16 for both CommonJS and ES Module projects, not only for the latter.

After all, node16+node16 are the settings that allows you to correctly transpile dynamic import().

The current default of commonjs+node does not let you use ESM packages inside a CommonJS project, even if a dynamic import was used, it fails quietly (#45125).