Skip to content

chore: align tsconfig with project standard #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jan-kubica merged 1 commit into from
Mar 24, 2026
Merged

chore: align tsconfig with project standard #74

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 17 additions & 11 deletions tsconfig.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,25 +1,31 @@
{
"compilerOptions": {
"target": "ES2022",
"lib": ["ES2022"],
"module": "ESNext",
"moduleResolution": "bundler",
"types": ["bun-types"],
"esModuleInterop": true,
"skipLibCheck": true,
"target": "ES2023",
"lib": ["ESNext"],
Copy link
Copy Markdown

@greptile-apps greptile-apps bot Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 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!

"allowJs": true,
"resolveJsonModule": true,
"moduleDetection": "force",
"verbatimModuleSyntax": true,
Comment on lines +3 to +10
Copy link
Copy Markdown

@greptile-apps greptile-apps bot Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 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,

"module": "Preserve",
"moduleResolution": "Bundler",
"noEmit": true,
Comment on lines +3 to +13
Copy link
Copy Markdown

@devin-ai-integration devin-ai-integration bot Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚩 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.

Open in Devin Review

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

"strict": true,
"exactOptionalPropertyTypes": true,
"noUncheckedIndexedAccess": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noFallthroughCasesInSwitch": true,
"noImplicitOverride": true,
"noImplicitReturns": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"useUnknownInCatchVariables": true,
"forceConsistentCasingInFileNames": true,
"skipLibCheck": true,
"noUncheckedIndexedAccess": true,
"exactOptionalPropertyTypes": true,
"paths": {
"#checksums/*": ["./src/_checksums/*"],
"#util/*": ["./src/_util/*"]
}
},
"include": ["src"]
"include": ["src"],
"exclude": ["node_modules"]
}
Loading