chore: align tsconfig with project standard

[jan-kubica]

Summary

• Align tsconfig.json with the project-wide standard (from @stll/anonymize)
• Key changes: target ES2022 -> ES2023, lib ES2022 -> ESNext, module ESNext -> Preserve
• Add missing flags: allowJs, resolveJsonModule, moduleDetection, verbatimModuleSyntax, noEmit, esModuleInterop
• Remove types field (not needed with skipLibCheck)
• Preserve paths configuration for #checksums/* and #util/*
• Add exclude: ["node_modules"]

Test plan

• npx tsc --noEmit passes with zero errors (after bun install)

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 1 additional finding in Devin Review.

[devin-ai-integration]

🚩 Removal of types: ["bun-types"] doesn't affect src/ but limits IDE support for tests/scripts

The old config explicitly included bun-types via "types": ["bun-types"]. This has been removed entirely. Since include is ["src"] and no file in src/ imports from bun:* or uses Bun.* globals, this has no effect on type-checking the source code. However, __test__/*.test.ts files import from "bun:test" and __test__/parse.test.ts imports Glob from "bun". Without bun-types in the tsconfig, IDEs resolving types via the root tsconfig won't provide IntelliSense for these test files. This doesn't break bun test at runtime (Bun resolves its own built-in types), but it may degrade the developer experience. Bun's own documentation recommends keeping "types": ["bun-types"] in tsconfig for editor integration.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[greptile-apps]

Greptile Summary

This PR aligns tsconfig.json with the project-wide TypeScript standard shared across the @stll monorepo (sourced from @stll/anonymize). The changes are purely configuration — no source code is touched — and the author confirms npx tsc --noEmit passes cleanly after the update.

Key changes and observations:

• target bumped ES2022 → ES2023 and lib widened to ["ESNext"]; since noEmit: true is now set and the actual build is delegated to tsdown, TypeScript won't downcompile, so the lib/target mismatch is low-risk but could allow use of post-ES2023 APIs without a type error.
• module changed from "ESNext" to "Preserve" (TypeScript 5.4+), which preserves each file's detected module format rather than normalising everything to ESM — appropriate for a type-check-only config.
• verbatimModuleSyntax: true is added alongside the existing esModuleInterop: true; these two flags are semantically redundant — verbatimModuleSyntax supersedes esModuleInterop per the TypeScript docs.
• types: ["bun-types"] is removed; while the stated reason ("not needed with skipLibCheck") is inaccurate (the two options serve unrelated purposes), the removal is safe here because all test files live in __test__/, which is outside the include: ["src"] scope, and no source file in src/ uses Bun.* APIs.
• noEmit: true is added, which correctly reflects that tsc is used only for type checking while tsdown handles emission.

Confidence Score: 5/5

• Safe to merge — config-only change with no source modifications and a passing tsc --noEmit verification.
• Only tsconfig.json is modified; no runtime behaviour is changed. The two style-level observations (esModuleInterop redundancy and lib/target mismatch) are low-risk in a noEmit setup where tsdown owns the actual build.
• No files require special attention.

Important Files Changed

Filename	Overview
tsconfig.json	Aligns compiler options with the project-wide standard from @stll/anonymize; two minor style-level observations: esModuleInterop is redundant alongside verbatimModuleSyntax, and lib: ["ESNext"] is broader than target: "ES2023".

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Source files\n(src/**/*.ts)"] -->|"include: ['src']"| B["tsc --noEmit\n(type checking only)"]
    B -->|"noEmit: true\nno JS output"| C["✅ Type errors caught"]
    A -->|"build script"| D["tsdown\n(bundler)"]
    D --> E["dist/ output\n(JS + .d.ts)"]
    F["__test__/**/*.test.ts"] -.->|"excluded from tsconfig\nrun directly by Bun"| G["bun test"]

    style B fill:#dbeafe,stroke:#3b82f6
    style D fill:#dcfce7,stroke:#22c55e
    style F fill:#fef9c3,stroke:#eab308

Loading

_{Reviews (1): Last reviewed commit: "chore: align tsconfig with project stand..." | Re-trigger Greptile}

[greptile-apps]

esModuleInterop and verbatimModuleSyntax are semantically redundant

Both esModuleInterop: true (line 3) and verbatimModuleSyntax: true (line 10) are set. verbatimModuleSyntax was introduced in TypeScript 5.0 as a stricter, superseding alternative to the patterns esModuleInterop enables — the TypeScript docs explicitly note that verbatimModuleSyntax makes esModuleInterop (and allowSyntheticDefaultImports) redundant.

Since noEmit: true is also set, there is no runtime impact, but including both creates unnecessary confusion about which setting governs import behaviour. If the @stll/anonymize standard template includes esModuleInterop, it may be worth confirming whether that package also sets verbatimModuleSyntax, or whether esModuleInterop can simply be omitted here.

Suggested change

	"esModuleInterop": true,
	"skipLibCheck": true,
	"target": "ES2023",
	"lib": ["ESNext"],
	"allowJs": true,
	"resolveJsonModule": true,
	"moduleDetection": "force",
	"verbatimModuleSyntax": true,
	"skipLibCheck": true,
	"target": "ES2023",
	"lib": ["ESNext"],
	"allowJs": true,
	"resolveJsonModule": true,
	"moduleDetection": "force",
	"verbatimModuleSyntax": true,

[greptile-apps]

lib: ["ESNext"] is broader than target: "ES2023"

Setting lib to ["ESNext"] makes all cutting-edge TypeScript type definitions available (e.g. Promise.try, Iterator helpers, future Array methods), even though the target is pinned to ES2023. Because noEmit: true is set and the actual build is performed by tsdown, TypeScript won't downcompile anything — but the mismatch means the type checker will happily accept code that uses APIs not yet available in ES2023 runtimes.

If the intent is to match the @stll/anonymize standard exactly, this is fine as-is. If the intent is to enforce that only APIs available in ES2023 are used in source, "lib": ["ES2023"] would provide that guardrail.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[jan-kubica]

LGTM. include: ["src"] with the existing paths aliases is correct. Merged. CC on behalf of @jan-kubica