try use tsrs #44448

Activity

1. dosubot commented on Oct 20, 2026

   

   dosubotBot

   on Oct 20, 2026 – with DosuBot

   More actions

   I’d try it as an opt-in benchmark first, not replace the required type checker yet.

   The promising part is that tsrs aims to preserve TypeScript’s behavior rather than introduce a new language. Cloudflare reports up to 8× faster checking and about 70% less memory than TypeScript 7.0 with matched worker counts. Those are their benchmarks, though, not evidence of the same gains on Dify. The release is explicitly experimental, and they acknowledge remaining compatibility differences. [1]

   For Dify, there’s a clear starting point: web/package.json has a separate type-check: tsc script, distinct from the build commands. That makes standalone type checking a sensible trial scope without changing the bundler. [2]

   I’d evaluate it by:

   • Running it alongside the existing checker on the same revision and configuration.
   • Comparing diagnostics and exit status, not just speed.
   • Measuring cold and incremental check time and peak memory on developer machines and CI.
   • Keeping the current checker authoritative until any differences are understood.

   My vote is yes to experimenting, with adoption based on Dify-specific results rather than the headline benchmark.

   To reply, just mention @dosu.

   ---

   Docs are dead. Just use Dosu.

   
2. hyoban commented on Oct 21, 2026

   

   hyoban

   on Oct 21, 2026 – with ChatGPT Codex Connector

   Last edited by hyoban

   Member

   More actions

   I tried tsrs@0.18.0-ts7.1.0-dev.20260929 locally on Dify. Standalone type checking is much faster, but the main migration obstacle is integration with our existing type-aware linting.

   Our vp check enables both typeAware and typeCheck. Oxlint uses tsgolint, backed by TypeScript Go, for both. Its type-aware rules need access to the compiler's program and type information; there is currently no configuration switch to use tsrs as that backend. Moving compiler diagnostics to tsrs therefore still leaves the Go engine running for lint rules, with two engines doing overlapping work. Disabling typeAware would lose checks that a compiler alone does not replace. See the Oxlint architecture; the tsrs announcement describes Oxlint type-aware integration as future exploration.

   For the full repository check workflow, the local trial measured:

   Workflow	Median elapsed time	Median sampled peak process-tree RSS
   Existing vp check (typed lint + type checking), then ESLint	41.96 s	6.73 GiB
   vp check (typed lint only), then ESLint, then tsrs workspace checks	36.07 s	7.32 GiB

   That is about 14% less elapsed time, with no observed memory improvement for the overall workflow. These are three runs per mode in alternating order on an M4 Pro / 24 GiB machine, using the same trial working tree based on e7c2c6f. Task caching was disabled and the web incremental cache was removed before each run; OS caches were not cleared. RSS was sampled across the process tree and can double-count shared pages. The tsrs variant also checked all 13 workspace packages, including files excluded by the existing Oxlint scope, so this compares the proposed workflows rather than identical compiler coverage. This is local evidence, not a CI benchmark.

   There are also a few adoption details to resolve:

   • Version alignment: the tested tsrs follows TS 7.1 development code, while our native compiler is 7.0.2. It reported eight additional TS7031 errors in test mocks, but the matching official TS 7.1 nightly reported exactly the same errors. Those differences should not be mistaken for tsrs-specific regressions.
   • Platform coverage: this release ships native binaries for macOS ARM64 and Linux x64/ARM64, but not Windows or Intel Macs. A migration needs a fallback that preserves validation failures.
   • Installation policy: our pnpm trustPolicy: no-downgrade rejected this exact release during the trial. Adoption would need a reviewed, narrowly scoped trust exception.

   Replacing standalone type-check commands is feasible. Replacing the shared engine behind our full check workflow needs upstream Oxlint/tsrs integration; until then, the tradeoff is a modest end-to-end speedup against maintaining two type engines and fallback behavior.

   For timing, I would treat TypeScript 7.1 stable as a reassessment milestone, rather than an automatic trigger to adopt tsrs. Once Vite+/tsgolint supports it, we should upgrade the existing toolchain and rerun the comparison against a tsrs release targeting the same TypeScript version. The current 14% advantage may change with that baseline.

   An opt-in standalone type-check command could come earlier, provided diagnostics match and platform fallback is reliable. For making tsrs the default in the main check workflow, I would prefer to wait until Oxlint can use it for both compiler diagnostics and type-aware rules, then verify correctness, elapsed time, and memory on CI. At present, saving roughly six seconds per full local check without a memory improvement does not, in my view, justify the added maintenance of two type engines across the project.

   Update — related implementation: maschwenk/tsrslint provides a third-party Rust replacement for the tsgolint backend, built on tsrs. I missed this in the assessment above: Oxlint already exposes OXLINT_TSGOLINT_PATH to select an alternative backend, and tsrslint implements both type-aware rules and --type-check diagnostics. This offers a concrete route to keeping typeAware and typeCheck enabled with a shared Rust backend, rather than retaining Go linting alongside a separate tsrs check.

   It is worth testing on Dify now, without waiting for TypeScript 7.1 stable. We have not yet tested this backend with our Vite+ workflow. Its documented rule baseline is tsgolint 7.0.2002 plus a rule from 7.0.2003, while our installed version is 7.0.2004; diagnostic parity and compatibility with the internal backend protocol still need verification.

   The 14% improvement above applies only to the separate-checker trial, not tsrslint. A useful next comparison is the existing vp check against the same workflow using tsrslint for both typed lint and compiler diagnostics, measuring correctness, time, and memory before deciding on default adoption.
3. hyoban

   self-assigned this

   on Oct 21, 2026
4. hyoban

   closed this as completedin #44610on Oct 23, 2026