Add local official plugin install verification #353

Closed
opened 2026-06-06 23:59:33 +00:00 by steve · 0 comments
Owner

Official external plugin releases need a local install verification gate that
builds the repo packages, installs the packaged result through the workspace
distribution flow, and proves each plugin activates. The current checks missed
broken Docs chunk packaging and Graph runtime metadata that referenced private or
uncatalogued host modules.

Problem

  • lapis-docs can install a release whose runtime fallback points at a missing
    hashed local chunk.
  • lapis-graph can produce release metadata that retains unsupported
    @lapis-notes/ui/* and svelte/internal/* imports.
  • Large plugin installs can appear frozen during verification/extraction/staging
    because progress reporting is too coarse.
  • Existing workspace E2E coverage installs some official plugins from generated
    registry metadata, but does not build and install each local external plugin
    bundle before asserting runtime behavior.

Goal

Add a local official plugin install verification path for all current external
official plugins and make installer progress visible enough to diagnose large
plugin installs such as Docs.

Scope

  • Build/package validation for the official external plugin bundle set.
  • Installer progress event improvements for download, verification, extraction,
    staging, install, load, enable, completion, and failure paths.
  • Workspace E2E coverage that installs and smoke-verifies every local official
    external plugin bundle.
  • CI and release workflow wiring for the new verification gate.
  • Spec updates for plugin registry/runtime/testing expectations.

Non-goals

  • Publishing the fixed production plugin releases as part of this code change.
  • Changing production registry trust keys.
  • Adding deep feature-parity coverage beyond one representative runtime
    assertion per official external plugin.

Acceptance Criteria

  • The tested plugin matrix is derived from the official release definitions and
    fails when an official external plugin lacks an E2E scenario.
  • Official plugin builds only externalize generated public host modules; private
    Svelte internals and UI subpaths are bundled or fail validation.
  • Lapis official external plugins publish ESM runtime entries only; CommonJS is
    reserved for legacy Obsidian-compatible community plugin loading.
  • Release packaging validates static runtime entry/fallback dependency graphs so
    referenced local JS chunks are present in the signed bundle.
  • Installer progress includes determinate file/byte progress for verification
    and staging, and large installs do not have silent progress gaps in E2E.
  • Installs launched from a missing-editor/file-open flow enable the plugin by
    default and continue opening the file after installation. Registry installs
    either enable by default or present a clear enable action instead of silently
    leaving the installed plugin inactive.
  • pnpm test:official-plugins builds local plugin bundles, serves a signed
    local registry fixture, installs every external official plugin through
    pluginDistribution.install(..., { requireOfficial: true, enable: true }),
    asserts official provenance/enabled state, reload persistence, and one runtime
    behavior per plugin.
  • Shared CI verification runs the new official plugin install test.
  • Relevant specs document the local install verification and progress contract.

Implementation Notes

  • Use test-only signing keys and registry sources for local E2E; production
    embedded trust keys remain unchanged.
  • Prefer shared official plugin Vite/release helpers over per-plugin ad hoc
    pruning.
  • Preserve existing download progress fields for compatibility while adding
    generic processed byte/file fields.

Suggested Files or Specs To Inspect

  • spec/src/30-cross-package-contracts/plugin-registry.md
  • spec/src/30-cross-package-contracts/plugin-runtime.md
  • spec/src/30-cross-package-contracts/plugin-host-boundary.md
  • spec/src/40-testing/current-state.md
  • scripts/publish-official-plugin-assets.mjs
  • scripts/plugin-release.mjs
  • packages/api/src/lib/plugin-distribution/
  • packages/workspace/e2e/
  • packages/plugins/*/vite.config.ts
  • packages/notebook/vite.config.ts

Validation Commands

  • pnpm check:all
  • pnpm test
  • pnpm test:smoke
  • pnpm test:daily-use
  • pnpm test:official-plugins
  • mdbook build spec
  • pnpm backlog:verify-commit @-
  • pnpm backlog:doctor --strict

Follow-up Tasks

  • Publish new production official plugin versions for any broken immutable
    releases, at least Docs and Graph, after this gate is passing.

Implementation Summary

Implemented local official plugin install verification, ESM-only official plugin packaging, install progress/default-enable updates, and specs.

Official external plugin releases need a local install verification gate that builds the repo packages, installs the packaged result through the workspace distribution flow, and proves each plugin activates. The current checks missed broken Docs chunk packaging and Graph runtime metadata that referenced private or uncatalogued host modules. ## Problem - `lapis-docs` can install a release whose runtime fallback points at a missing hashed local chunk. - `lapis-graph` can produce release metadata that retains unsupported `@lapis-notes/ui/*` and `svelte/internal/*` imports. - Large plugin installs can appear frozen during verification/extraction/staging because progress reporting is too coarse. - Existing workspace E2E coverage installs some official plugins from generated registry metadata, but does not build and install each local external plugin bundle before asserting runtime behavior. ## Goal Add a local official plugin install verification path for all current external official plugins and make installer progress visible enough to diagnose large plugin installs such as Docs. ## Scope - Build/package validation for the official external plugin bundle set. - Installer progress event improvements for download, verification, extraction, staging, install, load, enable, completion, and failure paths. - Workspace E2E coverage that installs and smoke-verifies every local official external plugin bundle. - CI and release workflow wiring for the new verification gate. - Spec updates for plugin registry/runtime/testing expectations. ## Non-goals - Publishing the fixed production plugin releases as part of this code change. - Changing production registry trust keys. - Adding deep feature-parity coverage beyond one representative runtime assertion per official external plugin. ## Acceptance Criteria - The tested plugin matrix is derived from the official release definitions and fails when an official external plugin lacks an E2E scenario. - Official plugin builds only externalize generated public host modules; private Svelte internals and UI subpaths are bundled or fail validation. - Lapis official external plugins publish ESM runtime entries only; CommonJS is reserved for legacy Obsidian-compatible community plugin loading. - Release packaging validates static runtime entry/fallback dependency graphs so referenced local JS chunks are present in the signed bundle. - Installer progress includes determinate file/byte progress for verification and staging, and large installs do not have silent progress gaps in E2E. - Installs launched from a missing-editor/file-open flow enable the plugin by default and continue opening the file after installation. Registry installs either enable by default or present a clear enable action instead of silently leaving the installed plugin inactive. - `pnpm test:official-plugins` builds local plugin bundles, serves a signed local registry fixture, installs every external official plugin through `pluginDistribution.install(..., { requireOfficial: true, enable: true })`, asserts official provenance/enabled state, reload persistence, and one runtime behavior per plugin. - Shared CI verification runs the new official plugin install test. - Relevant specs document the local install verification and progress contract. ## Implementation Notes - Use test-only signing keys and registry sources for local E2E; production embedded trust keys remain unchanged. - Prefer shared official plugin Vite/release helpers over per-plugin ad hoc pruning. - Preserve existing download progress fields for compatibility while adding generic processed byte/file fields. ## Suggested Files or Specs To Inspect - `spec/src/30-cross-package-contracts/plugin-registry.md` - `spec/src/30-cross-package-contracts/plugin-runtime.md` - `spec/src/30-cross-package-contracts/plugin-host-boundary.md` - `spec/src/40-testing/current-state.md` - `scripts/publish-official-plugin-assets.mjs` - `scripts/plugin-release.mjs` - `packages/api/src/lib/plugin-distribution/` - `packages/workspace/e2e/` - `packages/plugins/*/vite.config.ts` - `packages/notebook/vite.config.ts` ## Validation Commands - `pnpm check:all` - `pnpm test` - `pnpm test:smoke` - `pnpm test:daily-use` - `pnpm test:official-plugins` - `mdbook build spec` - `pnpm backlog:verify-commit @-` - `pnpm backlog:doctor --strict` ## Related Issues ## Follow-up Tasks - Publish new production official plugin versions for any broken immutable releases, at least Docs and Graph, after this gate is passing. ## Implementation Summary Implemented local official plugin install verification, ESM-only official plugin packaging, install progress/default-enable updates, and specs. <!-- backlog:task_id=TASK-PLUGIN-REGISTRY-LOCAL-INSTALL-E2E source_spec=spec/src/30-cross-package-contracts/plugin-registry.md -->
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lapis-notes/lapis#353
No description provided.