fix(npm): unblock portal-v0.1.0 publish + bump endpoint-manager devDeps#99
Merged
Merged
Conversation
…+ 2 HIGH) Closes 3 Dependabot alerts on the test-only happy-dom package: - #1 CRITICAL CVE-2025-61927 / GHSA-37j7-fg3j-429f — VM Context Escape can lead to Remote Code Execution - #2 HIGH CVE-2026-33943 / GHSA-6q6h-j7hj-3r64 — ECMAScriptModuleCompiler unsanitized export-name interpolation - #3 HIGH CVE-2026-34226 / GHSA-w4gp-fjgq-3q4g — fetch credentials use page-origin cookies instead of target happy-dom is the vitest test environment for @webhookengine/endpoint-manager. It is a devDependency only — never ships in the published package — so the production blast radius for portal-v0.1.0 consumers is zero. The CVE windows still affect any contributor running 'bun run test' locally, so bumping is the right call. The 17 → 20 major hop is non-breaking for our usage: the 42-test vitest suite passes unchanged (5 test files, 1.01 s), bun run typecheck / lint / build all clean. happy-dom 20's API drift is around DOM corner-cases we do not exercise (we only use it for fetch + DOM rendering of React components in tests).
Two coupled fixes that unblock the @webhookengine/endpoint-manager v0.1.0 npm publish: 1. samples/portal-host/package.json — '@webhookengine/endpoint-manager': 'workspace:*' → '*'. The portal-v0.1.0 publish workflow failed with 'npm error EUNSUPPORTEDPROTOCOL — Unsupported URL Type "workspace:"' because npm 10's publish path scans the workspace graph and rejects the workspace: protocol literal. The sample's '*' range still resolves to the local workspace member during Bun monorepo dev (Bun's workspace resolver picks the workspace package over the registry for any catch-all range), and stops npm from choking when it crawls the graph during publish. The sample's README already explains that consumers should npm install @webhookengine/endpoint-manager — that contract is unchanged. 2. packages/endpoint-manager — devDeps brought current to close the security window from the happy-dom CVE chain (PR #98) and unify on the Vite 8 / Vitest 4 line: peerDependencies: react ^19.0.0 → ^19.2.6 react-dom ^19.0.0 → ^19.2.6 devDependencies: @testing-library/jest-dom ^6.6.3 → ^6.9.1 @testing-library/react ^16.3.0 → ^16.3.2 @vitejs/plugin-react ^4.5.2 → ^6.0.1 (major) tsup ^8.5.0 → ^8.5.1 vite ^6.3.5 → ^8.0.11 (two majors — matches the dashboard's Vite 8 line) vitest ^3.2.1 → ^4.1.5 (major) Verification (all clean from the workspace root after bun install): packages/endpoint-manager/ bun run typecheck → clean bun run lint → clean bun run test → 42/42 pass in 847ms bun run build → ESM 75ms, DTS 489ms src/dashboard/ bun run typecheck → clean (no regression) bun run lint → clean bun run build → clean (chunk-size warning is the existing CodeMirror/Recharts one) samples/portal-host/ bun run build → clean, 245.73 kB / 72 kB gz Vitest 4 prints a one-line warning ('Both esbuild and oxc options were set. oxc options will be used'). Caused by the existing 'esbuild: { jsx: "automatic" }' in vitest.config.ts; vitest 4 routes JSX through the oxc transformer instead. Tests still run correctly. The config can be cleaned up in a follow-up — non-blocking for the publish. After this PR merges, the portal-v0.1.0 tag needs to be force-moved (delete + repush) so publish-portal.yml retriggers against the fixed main. The npm registry has nothing under @webhookengine/endpoint-manager yet (the prior workflow run failed before the publish step), so the tag move has no published-version side effect.
voyvodka
added
dependencies
…nd-portal-publish-fix # Conflicts: # bun.lock
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.
Summary
Two coupled fixes that unblock the
@webhookengine/endpoint-managerv0.1.0 npm publish (the first publish workflow on theportal-v0.1.0tag failed; the npm registry has no published version yet).Fix 1 — workspace protocol unblocks npm publish
samples/portal-host/package.json:"@webhookengine/endpoint-manager": "workspace:*"→"*".The portal-v0.1.0 publish workflow failed with:
npm 10's publish path scans the workspace graph and rejects the
workspace:protocol literal. The sample's*range still resolves to the local workspace member during Bun monorepo dev (Bun's workspace resolver picks the workspace package over the registry for any catch-all range), and stops npm from choking when it crawls the graph during publish. The sample's README already explains that consumers shouldnpm install @webhookengine/endpoint-manager— that contract is unchanged.Fix 2 — devDeps freshen
Brought current to close the security window from the happy-dom CVE chain (PR #98) and unify on the Vite 8 / Vitest 4 line:
react(peer)^19.0.0^19.2.6react-dom(peer)^19.0.0^19.2.6@testing-library/jest-dom^6.6.3^6.9.1@testing-library/react^16.3.0^16.3.2@vitejs/plugin-react^4.5.2^6.0.1tsup^8.5.0^8.5.1vite^6.3.5^8.0.11vitest^3.2.1^4.1.5Verification (all clean from workspace root after
bun install)packages/endpoint-managertypecheckpackages/endpoint-managerlintpackages/endpoint-managertestpackages/endpoint-managerbuildsrc/dashboardtypechecksrc/dashboardlintsrc/dashboardbuildsamples/portal-hostbuildVitest 4 prints a one-line warning ("Both esbuild and oxc options were set. oxc options will be used"). Caused by the existing
esbuild: { jsx: "automatic" }invitest.config.ts; vitest 4 routes JSX through the oxc transformer instead. Tests still run correctly. The config cleanup is a follow-up — non-blocking for the publish.After merge
The
portal-v0.1.0tag needs to be force-moved (delete + repush) sopublish-portal.ymlretriggers against the fixed main. The npm registry has nothing under@webhookengine/endpoint-manageryet (the prior workflow run failed before the publish step), so the tag move has no published-version side effect.Test plan
packages/endpoint-manager42/42 vitest pass