Aravind
1775395256
Phases 0-3 of the JS/JSX -> TS/TSX migration. No runtime behaviour changes:
every converted file emits byte-identical JavaScript, verified file by file.
Phase 0 - harness hardening, before any rename:
- scripts/ssr-resolve.mjs wraps `ssrLoadModule` so the ~170 literal module
paths in the check scripts resolve .js/.jsx/.ts/.tsx. Without it the first
rename would have silently destroyed the 1642-check suite that guards the
Owliver flow.
- eslint.config.js gains a TypeScript block. Its `files` globs listed only
{js,mjs,cjs,jsx}, so a renamed file would have dropped out of the run while
`eslint .` went on exiting 0 - the quietest failure mode available.
- MIGRATION_BASELINE.md records the measured starting point, including the
pre-existing seed-fixture failure and the already-broken standalone
owliver-baseline.mjs, so neither is later mistaken for migration damage.
Phase 1 - tsconfig.json succeeds jsconfig.json, carrying every option across at
its old value. `types` moves from [] to ["vite/client"], which fixes the eight
import.meta errors; @types/node is deliberately excluded so setTimeout stays a
number in browser code. allowJs and checkJs stay on, strict stays off.
Phase 2 - src/types/{api,entities,user}.ts. Transport envelope, error shape,
the entity-name union (the same 18 names are written down twice today, in
httpClient and base44Client, with nothing checking they agree), and the user
record. Every field transcribed from the API contract, the migrations and the
/me projection in me.go - not inferred. Entity record shapes are deliberately
absent: derivable, but nothing consumes them yet.
Phase 3 - nine leaf utilities renamed to .ts with annotations added only where
they could be established from existing usage. Entity records are typed `any`
with a comment naming what they are, rather than a guessed interface.
Verified: tsc 64 errors (65 before; one pre-existing TS2559 genuinely fixed,
none introduced), lint unchanged at 0 errors, skill-check 1641/1642 with only
the known failure, Owliver baseline section 59/59 green, production build
succeeds with the API origin inlined.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HBG1wnuRfJKCstGB8Fekr8
85 lines
4.0 KiB
JSON
85 lines
4.0 KiB
JSON
{
|
|
/* The TypeScript configuration, succeeding `jsconfig.json`.
|
|
Deliberately a translation of what was already there rather than a fresh
|
|
start: every option below that existed in jsconfig carries its old value,
|
|
so the first day of the migration checks exactly what the last day before
|
|
it checked. The four additions are marked.
|
|
|
|
`jsconfig.json` is left in place for now and is inert — TypeScript ignores
|
|
it wherever a `tsconfig.json` sits beside it. It is removed in the final
|
|
phase, once nothing is asking for it. */
|
|
"compilerOptions": {
|
|
"baseUrl": ".",
|
|
"paths": {
|
|
"@/*": ["./src/*"]
|
|
},
|
|
"jsx": "react-jsx",
|
|
"module": "esnext",
|
|
"moduleResolution": "bundler",
|
|
"lib": ["esnext", "dom", "dom.iterable"],
|
|
"target": "esnext",
|
|
|
|
/* Vite builds; this config only ever checks. Stating it means no stray
|
|
output can appear next to a source file if anyone runs `tsc` directly. */
|
|
"noEmit": true,
|
|
|
|
/* The two that make an incremental migration possible. `allowJs` lets a
|
|
`.ts` file and a `.js` file import each other with no ceremony, so files
|
|
can be converted one at a time instead of in one unreviewable commit;
|
|
`checkJs` keeps the JSDoc-typed JavaScript under the same scrutiny it
|
|
has had all along, so nothing is lost in the meantime. Both go away at
|
|
the end of the migration, not before. */
|
|
"allowJs": true,
|
|
"checkJs": true,
|
|
|
|
/* NEW. esbuild compiles each file on its own and cannot see across them, so
|
|
a construct that needs whole-program knowledge — re-exporting a type as
|
|
if it were a value, most often — works under `tsc` and breaks in the
|
|
bundle. This makes tsc refuse what esbuild could not have done anyway. */
|
|
"isolatedModules": true,
|
|
|
|
/* NEW. macOS does not distinguish `Button` from `button`; CI does. Without
|
|
this, a mis-cased import is a green local build and a red pipeline. */
|
|
"forceConsistentCasingInFileNames": true,
|
|
|
|
"skipLibCheck": true,
|
|
"allowSyntheticDefaultImports": true,
|
|
"esModuleInterop": true,
|
|
"resolveJsonModule": true,
|
|
|
|
/* CHANGED, from `[]`. The empty list suppressed every ambient type package,
|
|
which is why `import.meta.env` and `import.meta.glob` — Vite build-time
|
|
APIs, absent from the standard `ImportMeta` — were reported as errors in
|
|
eight places across the app.
|
|
|
|
Named explicitly rather than left to default, because the default pulls
|
|
in EVERYTHING under node_modules/@types, and `@types/node` is installed.
|
|
In browser code that would make `setTimeout` return a `NodeJS.Timeout`
|
|
instead of a number, which is wrong and quietly infectious: three
|
|
components store a timer handle in a `useRef` and would be typed against
|
|
a runtime they do not run on. Node's types belong to `vite.config.js` and
|
|
`scripts/`, neither of which this project includes. */
|
|
"types": ["vite/client"],
|
|
|
|
/* Off for now, and turned on a flag at a time later in the migration —
|
|
`noImplicitAny`, then `strictNullChecks`, then the rest. Enabling it here
|
|
would bury the ~70 real errors this project already has under several
|
|
hundred more, and the point of going file by file is that each step is
|
|
small enough to read. */
|
|
"strict": false
|
|
},
|
|
|
|
"include": ["src/**/*"],
|
|
|
|
/* Unchanged from jsconfig, and temporary. These three trees hold the densest
|
|
logic in the app — the transport layer, every hook, and the vendored UI
|
|
primitives — and none of it has ever been checked. Each exclusion is
|
|
removed by the phase that converts the tree behind it, so the error count
|
|
rises deliberately and in one identifiable place at a time.
|
|
|
|
Note that excluding a file only keeps it out of the root set: one that an
|
|
included file imports is still checked, which is why errors from `src/api`
|
|
and `src/lib` already show up today. */
|
|
"exclude": ["node_modules", "dist", "src/components/ui", "src/api", "src/lib"]
|
|
}
|