feat(registry): plugin compile report + /:name/:version/report API - #44
Merged
Conversation
Publish now discovers a plugin's server actions and persists them with the version; a new read route serves the compile report (declared capabilities + discovered actions) over HTTP. - ActionScanner port (registry-core) + SucraseActionScanner adapter: Worker-safe sucrase, Web Crypto ids matching the runtime's computeActionId - reg_versions.actions JSON column (migration 0006), threaded through commitVersion -> PackageVersion -> getPackage - ResolveService.report() + a thin report controller, bound in the composition root - Verified end-to-end on wrangler dev (real workerd): authenticated publish gated and stored in D1/R2, report served; failure gates (401/403/409/404) confirmed Also snapshots other in-progress registry working-tree changes.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
brika-registry | 3c9cca8 | Jul 04 2026, 06:44 PM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
brika-store | 3c9cca8 | Jul 04 2026, 06:45 PM |
Wire the published isolate compiler into the publish path: - manifest-validator calls compilePluginGate (rollup+sucrase, runs in the Worker) on the bricks/pages entrypoints: a stronger check than per-file syntax (catches unresolved imports), and it discovers the plugin's actions for the report - keep the cheap per-file sucrase sweep (compile-check) for BREADTH: compilePluginGate only sees browser entrypoints, so the sweep still covers a broken/garbage server `main`, blocks, and server-only plugins (anti-squat) - actions now flow from validate() -> commitVersion (drop the separate ActionScanner port + SucraseActionScanner adapter; delete the duplicated action-scan) - depend on @brika/compiler@0.4.0-00e5f35c9ec7 (nightly); Worker is 452 KiB gzip 842 tests, typecheck, lint, architecture, thin-routes green.
…points Feed compilePluginGate every declared entry - the server `main`, bricks, pages, and blocks - so unresolved imports are caught on SERVER code too, not just bricks/pages. Closes the publish-time blind spot (a broken import in main/blocks used to slip to the hub). Verified: all 8 shipped plugins still compile clean (action-stubbing keeps it from over-compiling server-action subtrees), and a new test proves a main with an unresolved import is now rejected. The system is now comprehensive: per-file sweep = syntax of every file (incl. dead/stubbed code); bundle gate = syntax + link of the whole reachable graph. 843 tests, typecheck, lint green.
…rage - test the compile gate returning discovered actions (the one uncovered branch in the validator: a plugin WITH an action, id matching the runtime) - sonar.coverage.exclusions += apps/registry/bench/** (a benchmark, not shippable code - it was 40 uncovered lines dragging new-code coverage below the gate)
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Plugin compile report + report API
Publishing a plugin now discovers its server actions and persists them with the version, and a new read route serves the compile report (declared capabilities + discovered actions) over HTTP.
What's new
GET /:name/:version/report->{ name, version, manifest, actions }(thin controller, edge-cached).ActionScannerport in@brika/registry-core(pure) +SucraseActionScanneradapter in the app: Worker-safe sucrase, action ids via Web Crypto that match the runtime'scomputeActionId(verified:listDevices@0844025241d0).reg_versions.actionsJSON column (migration0006, hand-authored per repo convention), threadedcommitVersion -> PackageVersion -> getPackage.ResolveService.report()composes the stored manifest + actions.Design notes
@brika/compiler/v8bundle-gate (the registry has no dependency on it and its own gate is the Worker-safe equivalent). No npm publish needed.manifest+ the newactions; manifest is not duplicated.Verified
wrangler dev(real workerd): migrate local D1 (through0006) -> seed scope/member/token -> authenticated publish@test/demo@1.0.0returned201and stored the tarball in R2 ->GET /@test/demo/1.0.0/reportreturned the manifest +listDevices@0844025241d0.401(no token),403(unowned scope),409(immutable re-publish),404(unknown-version report).bun run typecheck,bun run lint, and thepackages/apps/registry/architecturetest suites pass.