While restoring ESLint coverage (#567), I tried enabling stricter TypeScript checks to understand what they would reveal. They exposed several places where the code relies on assumptions that are not expressed in its types. I have kept that stricter-checking work out of the tooling fix so it can be considered separately.
Would there be interest in gradually strengthening these checks and types, through small PRs that preserve existing behavior?
Why this could help
The extension translates editor events into requests to the Flix compiler. Making the contracts at those boundaries explicit would help preserve the intended semantics and make changes easier to review.
One example is Job, which currently permits arbitrary fields through [param: string]: any. The relationship between a request and its payload is therefore largely established by reading its producers and consumers. Request-specific types could make required fields and valid combinations visible to both the compiler and contributors.
The investigation of job.src illustrates why this matters: an empty string represents valid source content, while absent content requests a disk read. Confusing those states previously caused stale content to be sent to the compiler, fixed in #520. Stronger types could help document such distinctions, alongside tests that protect their behavior.
This would also reduce how much implicit knowledge contributors need before safely changing the extension—particularly developers familiar with Flix’s type-safety principles who are less familiar with TypeScript or VS Code’s APIs.
Possible approach
- Start with one small area whose behavior and ownership can be established, rather than enabling stricter rules across the repository at once.
- Trace reported diagnostics back to the relevant contracts. Some may identify bugs; others may reflect valid assumptions that need a clearer representation.
- Prefer meaningful types and explicit inputs over casts, non-null assertions, or suppression comments added solely to satisfy a check.
- Add focused tests where a change affects behavior, then enable the relevant check for the migrated scope.
- Evaluate additional ESLint rules individually, prioritizing correctness over stylistic churn.
The server already uses TypeScript’s strict mode. Possible later steps include strict checking for the client and tests, followed by evaluating noUncheckedIndexedAccess and exactOptionalPropertyTypes separately.
The aim would be a codebase whose types explain more of its behavior, with fewer assumptions that maintainers and contributors must reconstruct by hand. I would welcome guidance on whether this direction is useful and which small area would make the best starting point.
While restoring ESLint coverage (#567), I tried enabling stricter TypeScript checks to understand what they would reveal. They exposed several places where the code relies on assumptions that are not expressed in its types. I have kept that stricter-checking work out of the tooling fix so it can be considered separately.
Would there be interest in gradually strengthening these checks and types, through small PRs that preserve existing behavior?
Why this could help
The extension translates editor events into requests to the Flix compiler. Making the contracts at those boundaries explicit would help preserve the intended semantics and make changes easier to review.
One example is Job, which currently permits arbitrary fields through [param: string]: any. The relationship between a request and its payload is therefore largely established by reading its producers and consumers. Request-specific types could make required fields and valid combinations visible to both the compiler and contributors.
The investigation of job.src illustrates why this matters: an empty string represents valid source content, while absent content requests a disk read. Confusing those states previously caused stale content to be sent to the compiler, fixed in #520. Stronger types could help document such distinctions, alongside tests that protect their behavior.
This would also reduce how much implicit knowledge contributors need before safely changing the extension—particularly developers familiar with Flix’s type-safety principles who are less familiar with TypeScript or VS Code’s APIs.
Possible approach
The server already uses TypeScript’s strict mode. Possible later steps include strict checking for the client and tests, followed by evaluating noUncheckedIndexedAccess and exactOptionalPropertyTypes separately.
The aim would be a codebase whose types explain more of its behavior, with fewer assumptions that maintainers and contributors must reconstruct by hand. I would welcome guidance on whether this direction is useful and which small area would make the best starting point.