feat(typescript-config): refine tsconfig.json for typescript v7 readiness

[kurone-kito]

Summary

Refine packages/typescript-config/tsconfig.json for TypeScript v7
readiness, per the issue's proposed change:

1. Deleted "strict": true and "esModuleInterop": true — both are
   mandatory, non-overridable defaults from TypeScript 6.0 onward, and
   Align workspace typescript devDependencies to ~6.0.3 #110 already put every internal consumer (example-cli,
   example-lib, sea-builder, vite-lib-config) on
   typescript ~6.0.3, so the deletion changes nothing observable for
   them.
2. Bumped peerDependencies.typescript from >=5.7.x to >=7.0.0
   and devDependencies.typescript from ~6.0.3 to ~7.0.2
   (current latest). Breaking for any external consumer still on
   TypeScript <7 — same class of peer-mismatch warning this workspace
   already tolerates for typedoc@0.28.20, not a hard failure.
3. Bumped target/lib from ES2023 to ES2024 (investigation
   below).

Investigation outcomes

target/lib → ES2024

Checked whether every engine in engines.node's full range
(^22.23.1 || ^24.2.0 || >=26.0.0) supports the runtime features
TypeScript 7's lib.es2024.*.d.ts exposes. The floor version,
Node.js 22.23.1, is what this environment actually runs, so I
checked it directly rather than reasoning from release notes:

$ node --version
v22.23.1
$ node -e "
console.log('Object.groupBy:', typeof Object.groupBy);
console.log('Map.groupBy:', typeof Map.groupBy);
console.log('Promise.withResolvers:', typeof Promise.withResolvers);
console.log('ArrayBuffer.prototype.transfer:', typeof ArrayBuffer.prototype.transfer);
console.log('String.prototype.isWellFormed:', typeof String.prototype.isWellFormed);
"
Object.groupBy: function
Map.groupBy: function
Promise.withResolvers: function
ArrayBuffer.prototype.transfer: function
String.prototype.isWellFormed: function

All present on the range's floor version. Node.js 24.2.0 and
26.0.0 ship strictly newer V8 releases, so they carry every feature
the floor already has. Compiling a file that calls all of the above
under typescript@7.0.2 with target/lib: "ES2024" type-checks
with zero errors. Decision: bumped to ES2024.

noErrorTruncation / preserveWatchOutput

Both vanish from tsc --showConfig's output under typescript@7.0.2
(confirmed, matching the issue's own finding), but --showConfig only
echoes options that were explicitly set somewhere in the config
chain — it does not enumerate implicit defaults at all (verified
with a bare {} tsconfig: --showConfig reports "compilerOptions": {}",
even though TypeScript still applies strict: true etc. during an
actual compile). So the vanished --showConfig entry doesn't imply
the option itself stopped working; I tested actual behavior instead:

• noErrorTruncation: compiled a file that produces a message long
  enough to truncate. Without the option, typescript@7.0.2 truncates
  with ...; with "noErrorTruncation": true, the full type is
  printed untruncated. Still takes effect.
• preserveWatchOutput: ran tsc -w under typescript@7.0.2 and
  captured raw bytes. Without the option, each recompilation is
  preceded by \x1b[2J\x1b[3J\x1b[H (clear screen + clear scrollback +
  cursor home); with "preserveWatchOutput": true, those escape codes
  are absent and output is only appended. Still takes effect.

Decision: kept both.

Acceptance-criteria note on --showConfig

The issue's last acceptance-criteria bullet expected
pnpm --filter @kurone-kito/typescript-config exec tsc --showConfig
against a consuming file to still show strict: true and
esModuleInterop: true after the deletions, as proof TypeScript 7
supplies both as mandatory defaults. As found above, --showConfig
does not enumerate implicit defaults at all (verified with a bare {}
config under typescript@7.0.2 — compilerOptions reports empty).
Both keys are absent from the resolved --showConfig output after
this change, exactly as they would be for any unset option,
regardless of TypeScript version.

The underlying claim — that TypeScript 7 still enforces both as
non-overridable defaults — is verified instead by actual compile
behavior:

• const v: string | null = null; v.length; still errors TS18047
  ('possibly null') under typescript@7.0.2 with no strict set
  anywhere in the config.
• "esModuleInterop": false still hard-errors TS5108 ("Option
  'esModuleInterop=false' has been removed") under the same version.

Test plan

• pnpm run lint passes
• pnpm run build succeeds across the workspace
• pnpm run test passes (68/68 tests, including
  test:ts's workspace-wide tsc --noEmit)
• packages/typescript-config/tsconfig.json no longer contains
  strict or esModuleInterop
• peerDependencies.typescript is >=7.0.0;
  devDependencies.typescript is ~7.0.2

Closes #111

Summary by CodeRabbit

• Chores
  • Updated TypeScript tooling and compilation settings to support the latest language standards.
  • Improved compatibility with ES2024 features and modern TypeScript projects.
  • No changes to the product’s public functionality or user-facing experience.

[coderabbitai]

Warning

Review limit reached

@kurone-kito, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 18 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 9ae7ddab-8d01-4010-897d-3ad33d8ca2fe

📥 Commits

Reviewing files that changed from the base of the PR and between 0e5f598 and 2f71d2c.

📒 Files selected for processing (5)

• packages/example-cli/tsconfig.json
• packages/example-lib/tsconfig.json
• packages/sea-builder/tsconfig.json
• packages/typescript-config/README.md
• packages/vite-lib-config/tsconfig.json

📝 Walkthrough

Walkthrough

The TypeScript configuration package now uses TypeScript 7. Its peer dependency requires TypeScript 7 or newer. The compiler target and library use ES2024. The explicit strict and esModuleInterop options were removed.

Changes

TypeScript 7 readiness

Layer / File(s)	Summary
TypeScript 7 dependency requirements packages/typescript-config/package.json	The development dependency changed to ~7.0.2. The peer dependency minimum changed to >=7.0.0.
ES2024 compiler configuration packages/typescript-config/tsconfig.json	The target and lib settings changed from ES2023 to ES2024. The explicit strict and esModuleInterop settings were removed.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related issues

• TypeScript v7 readiness for @kurone-kito/typescript-config #109 — The changes implement the issue’s TypeScript 7 dependency and shared configuration updates.

Possibly related PRs

• kurone-kito/builder-config#19 — Both PRs update TypeScript tooling and the shared TypeScript configuration.
• kurone-kito/builder-config#113 — Both PRs update the TypeScript dependency in packages/typescript-config/package.json.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The implementation meets the code objectives in #111, but showConfig does not display the required strict and esModuleInterop settings.	Resolve or revise the contradictory showConfig acceptance criterion, and provide an accepted verification that TypeScript 7 enforces both settings after removal.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the TypeScript configuration refinement and its TypeScript 7 readiness goal.
Description check	✅ Passed	The description covers the requested changes, investigations, acceptance-criteria caveat, and test results.
Out of Scope Changes check	✅ Passed	All reviewed changes are limited to TypeScript 7 readiness tasks defined in issue #111.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch issue/111-refine-typescript-config-tsconfig-for-ts-v7

Warning

Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/typescript-config/package.json`:
- Around line 36-37: Align the TypeScript peer requirement in
packages/typescript-config with the workspace’s supported compiler version by
either updating the root dependency and direct consumers (including
vite-lib-config, example-cli, example-lib, and sea-builder) to TypeScript 7 or
lowering the peer boundary to remain compatible with TypeScript ~6.0.3; ensure
the resulting workspace resolution satisfies all consumers consistently.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 3927c104-51a9-4588-a2b3-56f7edea9e6b

📥 Commits

Reviewing files that changed from the base of the PR and between 726f6bf and 0e5f598.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (2)

• packages/typescript-config/package.json
• packages/typescript-config/tsconfig.json

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (1)

packages/typescript-config/tsconfig.json:13

• lib was bumped to ES2024 here, but all in-repo consumers that extend this config currently override compilerOptions.lib to ['DOM', 'ES2023'] (e.g. packages/example-cli/tsconfig.json:3, example-lib:3, sea-builder:3, vite-lib-config:3). That means the ES2024 lib typings won’t actually apply to the workspace packages, and they’ll now be in a potentially confusing state of target: ES2024 (inherited) with lib: ES2023 (overridden). Consider updating those consumer tsconfigs (and the README example) to ['DOM', 'ES2024'] in the same change set, or reverting the base lib/target bump until the consumers are aligned.

    "lib": ["ES2024"],
    "module": "nodenext",

[kurone-kito]

Accepted — Copilot's review on commit 5430edf buried a real finding in a collapsed "Suppressed comments" section (never posted as a normal comment/thread): all four in-repo consumers (example-cli, example-lib, sea-builder, vite-lib-config) override compilerOptions.lib to ['DOM', 'ES2023'], which TypeScript replaces wholesale rather than merging with the base config — so the base's lib: ['ES2024'] bump had zero effect on any of them, leaving target: ES2024 (inherited) paired with lib: ES2023 (overridden).

Verified against the actual consumer tsconfig.json files, then updated every override (and the README's matching example) to ['DOM', 'ES2024'] to keep target/lib consistent workspace-wide. Fixed in 2f71d2c.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

[kurone-kito]

Rejected — coderabbitai[bot] did not review HEAD 2f71d2c (review limit reached / rate limited); this is not a completed review (source: #issuecomment-5241122683)

[github-actions]

F4 Cleanup Evidence (server-side fallback via post-merge-cleanup.yml)

Field	Value
Status	applied
Applied	10
Failed	0
Skipped	7
Permission-blocked	0
Posted by	post-merge-cleanup workflow