Skip to content

Fix webviews type errors and enforce svelte-check in CI - #885

Open
chrisdp wants to merge 3 commits into
masterfrom
fix/webviews-typecheck
Open

Fix webviews type errors and enforce svelte-check in CI#885
chrisdp wants to merge 3 commits into
masterfrom
fix/webviews-typecheck

Conversation

@chrisdp

@chrisdp chrisdp commented Aug 29, 2026

Copy link
Copy Markdown
Collaborator

The webviews have a type checker (npm run check in webviews/, running svelte-check), but nothing ran it. The production build is vite build, which transpiles without type checking, the root build/preversion scripts never invoked svelte-check, and no CI workflow ran it either. It was failing on master with 17 errors, unnoticed because every broken import was type-only, so vite erased them and the runtime bundle was unaffected.

Type errors

Two failure categories were involved:

  • webviews/src/views/RceManagementView/RceManagementView.svelte imported FirmwareVersionOut and SnapshotOut from roku-deploy; those names don't exist (the real exports are FirmwareVersion and Snapshot). Renamed all usages to match.
  • The same file also imported RceStateDevice from src/viewProviders/RceManagementViewProvider.ts, which pulled the provider's entire extension-side import graph (BaseWebviewViewProvider, managers, util, etc.) into svelte-check's program. That code gets compiled under webviews/tsconfig.json (@tsconfig/svelte, moduleResolution: "bundler", verbatimModuleSyntax), settings it was never written for, producing 15 interop errors in src/ files (dayjs/md5/JSZip "not callable", import x = require(...) rejections, Buffer mismatches).

Rather than patching each src/ error individually, the fix cuts the import graph: the RceStateDevice interface moved verbatim into a new leaf module, src/viewProviders/RceManagementViewContract.ts, whose only import is import type { DeviceStatus, DeviceType } from 'roku-deploy'. The provider re-exports the type so extension-side importers are unchanged, and the webview imports the contract file directly instead of the provider.

Warning cleanup

svelte-check also reported 211 warnings, so this PR takes it to zero so new problems stand out:

  • Expanded all 43 self-closing non-void elements (<vscode-divider /> style) to explicit open/close pairs; the HTML parser ignores the slash on non-void elements, so the self-closing form is ambiguous and Svelte 5 warns on it.
  • Added the one missing alt attribute.
  • Suppressed the remaining a11y interaction warnings and the SSR-only node_invalid_placement_ssr nesting warnings. Most of the a11y hits are false positives on vscode-* toolkit custom elements, which are natively interactive but opaque to svelte-check's static analysis; the webviews never server-render, so the SSR warnings don't apply.

Suppression is centralized in webviews/svelte.config.js via Svelte 5's compilerOptions.warningFilter. Unlike onwarn (a build hook only vite invokes), warningFilter is a compiler option, so vite build, svelte-check, and the VS Code svelte extension all honor it from the one config file. The repo previously had two other suppression mechanisms (an onwarn filter and a svelte.plugin.svelte.compilerWarnings map in .vscode/settings.json), both silently dead since the Svelte 5 upgrade renamed every warning code from dashes to underscores; both are removed.

Enforcement

A new root script check-webviews (cd webviews && npm run check) is added to the CI build workflow between lint and test, and to the preversion chain so releases can't ship with a red webviews typecheck. Root npm ci already installs webviews deps via postinstall, so CI needed no extra setup.

Aside from the markup expansions and the alt attribute, every edit is type-level, config, or a type-only import move; there's no runtime change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant