Summary
The repository currently uses one tsconfig.json that includes src, cli, and tests, while package scripts use the same TypeScript configuration for typecheck and for the build step via tsc && vite build.
Problem
A single TypeScript project for browser app code, test code, and CLI or config-adjacent code can blur execution boundaries and make compiler settings harder to reason about. It also makes it harder to tailor environment-specific types, module settings, and exclusions for Node-side tooling versus browser code.
Why this matters
The repository already has multiple execution contexts: browser application code, Playwright and Vitest tests, CLI code, and build tooling. Separating those contexts usually makes type errors more meaningful and reduces incidental coupling between unrelated parts of the project.
Proposed scope
- Keep a small root
tsconfig.json for shared compiler defaults.
- Add specialized configs such as
tsconfig.app.json, tsconfig.test.json, and tsconfig.node.json or equivalent.
- Point ESLint, tests, and build scripts at the most appropriate config for each context.
- Ensure browser-targeted code does not silently inherit Node-oriented assumptions, and vice versa.
Acceptance criteria
- App, tests, and Node-side tooling compile against dedicated TypeScript configs.
- Build and typecheck scripts remain easy to run and clearly documented.
- ESLint can target the correct project file for type-aware linting.
- No loss of strictness relative to the current compiler settings.
Suggested implementation notes
- Start by extracting shared strict defaults into a base config, then layer environment-specific configs on top.
- Update any editor, test, or CI integration that assumes a single root TypeScript project.
- Validate the split with a clean run of
typecheck, build, unit tests, and E2E tests.
Summary
The repository currently uses one
tsconfig.jsonthat includessrc,cli, andtests, while package scripts use the same TypeScript configuration fortypecheckand for the build step viatsc && vite build.Problem
A single TypeScript project for browser app code, test code, and CLI or config-adjacent code can blur execution boundaries and make compiler settings harder to reason about. It also makes it harder to tailor environment-specific types, module settings, and exclusions for Node-side tooling versus browser code.
Why this matters
The repository already has multiple execution contexts: browser application code, Playwright and Vitest tests, CLI code, and build tooling. Separating those contexts usually makes type errors more meaningful and reduces incidental coupling between unrelated parts of the project.
Proposed scope
tsconfig.jsonfor shared compiler defaults.tsconfig.app.json,tsconfig.test.json, andtsconfig.node.jsonor equivalent.Acceptance criteria
Suggested implementation notes
typecheck,build, unit tests, and E2E tests.