chore(web): consolidate on pnpm as the single lockfile#138
Merged
Conversation
package-lock.json was vestigial — Dockerfiles and CI use pnpm exclusively (pnpm install --frozen-lockfile), yet dependabot maintained BOTH lockfiles per bump, doubling the conflict surface (which produced the duplicate-key corruption fixed in #136). - Remove apps/web/package-lock.json and root package-lock.json. - Declare packageManager: pnpm@10.15.0 in root + apps/web package.json. - Drop the redundant version:10 from pnpm/action-setup in CI (packageManager is now the single source of the pnpm version); pin corepack prepare to match. - gitignore package-lock.json so a stray npm install can't reintroduce it. - Regenerate the root pnpm-lock.yaml, which had pre-existing drift (it referenced wavesurfer.js, not a root dep); root 'pnpm install --frozen-lockfile' now passes. apps/web/pnpm-lock.yaml (the web build's lockfile) is unchanged. Verified 'pnpm install --frozen-lockfile' passes at root and in apps/web.
ravirajsinh45
added a commit
that referenced
this pull request
Jul 9, 2026
… 's3') (#139) test_video_stream_returns_hls_proxy_url_with_token asserted "s3" not in url, where url = /stream/hls/master.m3u8?token=<random JWT>. The token is random and intermittently contains the substring 's3', failing the check and reddening CI unpredictably (e.g. on the #138 merge to main). The preceding assertion already confirms the URL is the HLS proxy path, so scope the guard to the part before ?token=: still catches a leaked presigned S3 URL (host/path carries 's3'), but ignores the opaque token. Verified: the s3-in-token case that flaked now passes, a presigned URL is still rejected, and 12/12 live runs pass.
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.
Context
Follow-up to the dependabot cleanup. The "dependabot can't parse pnpm-lock.yaml" error was not a lockfileVersion-9 limitation — dependabot has bumped
apps/webnpm deps against this exact v9 lockfile many times (#52/#55/#56/#25/#15). It failed only while the lockfile was corrupted (duplicate keys) by sibling squash-merges, which #136 already fixed. So npm dependabot is already working again.The real latent risk this addresses:
package-lock.jsonis 100% vestigial (grep finds zero references — Dockerfiles and CI usepnpm install --frozen-lockfileexclusively), yet dependabot maintained bothpackage-lock.jsonandpnpm-lock.yamlper bump — doubling the lockfile conflict surface that produced the corruption.Changes
apps/web/package-lock.json(10.9k lines) and rootpackage-lock.json(11k lines)."packageManager": "pnpm@10.15.0"in root +apps/webpackage.json.version: 10from bothpnpm/action-setup@v6steps —packageManageris now the single source of the pnpm version (v6 errors if both are set), pinning CI to 10.15.0 to match the lockfile.corepack prepare pnpm@10.15.0(dev + prod) to matchpackageManager..gitignore: ignorepackage-lock.jsonso a straynpm installcan't reintroduce a competing lockfile.pnpm-lock.yaml, which had pre-existing drift (it referencedwavesurfer.js@^7.12.4, not a root dep, so root--frozen-lockfilewas already failing onmain). Now passes.apps/web/pnpm-lock.yaml— the web build's actual lockfile — is unchanged.Verified locally
pnpm install --frozen-lockfilepasses at root (+ turbo 2.10.4) and in apps/web (using pnpm 10.15.0 per the pin, lockfile up to date).grepconfirms nothing referencespackage-lock.json.pnpm/action-setup+ Dockerfile changes are validated by this PR's CI (Frontend Build, Lint, Docker web image).