fix(init): emit ESM-compatible tsconfig for TypeScript projects

[DavertMik]

Fixes #5594

Problem

Running npx codeceptjs init and selecting TypeScript support emits a tsconfig.json that contradicts the rest of the setup init produces. init already installs tsx, typescript, @types/node and writes require: ['tsx/cjs'] for an ESM project — but the generated tsconfig is a leftover from the 3.x/ts-node era:

{
  "ts-node": { "files": true },     // ts-node is never installed by init
  "compilerOptions": {
    "module": "commonjs",           // wrong for an ESM ("type": "module") project
    ...
  }
}

• "ts-node": { files: true } does nothing — init installs tsx, not ts-node, and lib/utils/loaderCheck.js explicitly marks ts-node as "not recommended."
• "module": "commonjs" is wrong for the ESM 4.x design and makes editors flag the extensionless imports shown in docs/typescript.md.

Fix

Generate a tsconfig that matches the tsx/ESM setup init already configures:

• Drop the ts-node block.
• module: "commonjs" → "ESNext".
• Add moduleResolution: "bundler" so extensionless imports (import { admin } from './fixtures', exactly as the docs show) resolve the way tsx/esbuild actually resolve them. NodeNext would force .js extensions and contradict the docs.
• Bump target/lib es2018 → ES2022, in line with the repo's own tsconfig.

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022", "DOM"],
    "esModuleInterop": true,
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strictNullChecks": false,
    "types": ["codeceptjs", "node"],
    "declaration": true,
    "skipLibCheck": true
  },
  "exclude": ["node_modules"]
}

Note: tsx doesn't require a tsconfig.json at all — this file exists purely for editor IntelliSense and type checking, which is why it should reflect the real ESM/tsx setup.

Testing

test/runner/init_test.js passes (no test pins the tsconfig contents).

🤖 Generated with Claude Code