Skip to content

chore: remove vestigial apps/web/package-lock.json - #110

Open
martyy-code wants to merge 1 commit into
stagingfrom
chore/remove-npm-lockfile-from-apps-web
Open

martyy-code wants to merge 1 commit into
stagingfrom
chore/remove-npm-lockfile-from-apps-web

Conversation

@martyy-code

Copy link
Copy Markdown
Contributor

Context

The repo is a pnpm monorepo (packageManager: pnpm@10.34.5 in the root package.json). The file apps/web/package-lock.json was a stale artifact from the first commit; no CI step, build, or pnpm install reads it.

The lockfile still pinned:

Keeping it around is a permanent source of Dependabot noise that no longer matches the actual install graph. Dependabot scans all tracked lockfiles regardless of which tool the project uses.

Changes

  • delete apps/web/package-lock.json
  • add package-lock.json and yarn.lock to root .gitignore
  • add package-lock.json to apps/web/.gitignore (defense-in-depth)

Verification

🤖 Generated with Claude Code

The repo is a pnpm monorepo (packageManager: pnpm@10.34.5). The npm
lockfile in apps/web was a stale artifact from the first commit; it
still pinned vulnerable postcss@8.4.31 and old next/fumadocs versions,
and no CI step or build path reads it. Keeping it as a Dependabot
signal is pure noise.

- delete apps/web/package-lock.json
- ignore package-lock.json and yarn.lock at the repo root
- ignore package-lock.json in apps/web as defense-in-depth
@vercel

vercel Bot commented Oct 12, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
deessejs-errors-documentation Error Error Oct 12, 2026 8:45am UTC

codewizdave pushed a commit that referenced this pull request Oct 12, 2026
The previous wording said the direct `^8.5.15` range was the binding
constraint. That was wrong: caret semver already permits 8.5.29, and no
peer dependency was blocking the resolution. The real reason the
lockfile still pinned vulnerable postcss versions was that it was a
stale snapshot from the original commit; pnpm re-uses locked versions
until the lockfile is regenerated. The regen alone would have cleared
the alerts; this PR additionally raises the direct range to make the
manifest explicit. Also drops the outdated follow-up note that pointed
at PR #105, since PR #110 is the real cleanup for the npm lockfile.
@martyy-code martyy-code mentioned this pull request Oct 12, 2026
14 tasks

This branch had an error being deployed

1 failed deployment
Preview — 6c2f2776 Deployed Oct 12, 2026 by vercel[bot]
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.

2 participants