Would a low-risk JS type-checking pilot help the frontend?

[undergroundrap]

Hey everyone,

As the frontend grows, I’m wondering whether a small type-checking pilot would help catch state/shape bugs without forcing a big frontend migration.

I am not proposing an overnight JavaScript -> TypeScript rewrite, a bundler change, or converting large UI modules. The low-risk version I have in mind would be one of:

• add tsconfig.json with allowJs / checkJs for opt-in checking only;
• use JSDoc typedefs on one isolated static/js module;
• keep emitted/runtime files unchanged;
• keep CI non-disruptive at first, or scoped to the pilot file only;
• document what bugs this would catch before expanding it.

The goal would be to test whether type-checking reduces reviewer/debugging load, especially around shared frontend state objects, endpoint payloads, Cookbook server profiles, model endpoint rows, and other shape-heavy code.

Related note: I saw #68 raised broader project-structure/frontend concerns, but this poll is intentionally narrower. I’m not trying to reopen a large refactor discussion; I’m asking whether a small opt-in checkJs / JSDoc pilot would be useful enough to evaluate on its own.

If maintainers are interested, I’d be happy to propose a tiny first slice with no behavior changes and no build pipeline change.