PR labels

No PR without labels. Every pull request carries exactly one release-line label and at least one content label (typically one to three; see §2 for when more is right), applied right after it is created:

gh pr edit <n> --repo verdaccio/verdaccio --add-label "<release line>" --add-label "<content>"

Labels come from the existing list only (gh label list --repo verdaccio/verdaccio --limit 300, or https://github.com/verdaccio/verdaccio/labels); never create one.

Without gh, use the Labels sidebar on the PR page, or the REST API:

curl -s -X POST -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/repos/verdaccio/verdaccio/issues/<n>/labels \
  -d '{"labels":["<release line>","<content>"]}'

If you cannot apply labels at all, list the exact labels in your report so the author can add them.

1. Release-line label (always exactly one)

Base branch of the PR	Label
master (9.x)	7.x branch (next)
6.x	6.x branch (latest)

7.x branch (next) is the label in use for master; it predates 9.x and was kept so the history stays searchable. A port PR to another branch takes that branch's label, not the original's. 4.x and 5.x are deprecated with no further development: no PR targets them and their labels (4.x deprecated, 5.x branch (legacy)) are not used.

2. Content labels (typically one to three)

The content label answers "which mental folder does this PR open?". A focused PR takes two or three labels; a large multi-topic PR may take more, but every label must describe something central to the change, never something tangential.

By nature of the change:

• issue: bug — fixes a reported defect (pair it with the area).
• performance — measurable optimisation; the numbers go in the PR body.
• feat: breaking-change — breaks configuration, plugin interfaces, or the HTTP contract.
• dev: refactor — no behaviour change.
• dev: experiment — new behaviour behind a flag or an experimental package.
• dev: ci-build — workflows and CI only. dev: tooling — repo tooling, scripts, lint.
• dev: migration — toolchain or dependency-major migrations.
• docs, topic: readme, topic: testing, topic: e2e — documentation and test-only work.
• bot: dependencies — automated bumps (Renovate, Dependabot).

By area (topic: *): topic: proxy/uplinks, topic: web, topic: api, topic: search, topic: config, topic: token, topic: logging, topic: core, topic: middleware, topic: typescript, topic: devops, topic: offline-mode, topic: signature, topic: env-variables, topic: npm, topic: pnpm, topic: yarn-modern, topic: yarn-classic, topic: kubernetes, helm, Docker, topic: docker-compose, topic: nginx, topic: apache, topic: windows, React (UI components).

By subsystem: feat: auth, feat: storage, feat: notifications, plugin: local-storage, plugin: htpasswd, plugin: package-filter, plugin: verdaccio-memory, cmd: publish, cmd: unpublish, cmd: owner, cmd: npm team, cmd: npm deprecate.

Process labels: skip changeset (docs, tests, CI, tooling: nothing published changes, disables the changeset check; maintainers only, never on an external contributor's PR, see §3), WIP, dev: do-not-merge, dev: blocked.

3. Labels you do not apply

• skip changeset — maintainers only. It bypasses a CI gate, so it is applied by a maintainer after confirming the PR changes nothing published. An external contributor states in the PR body why no changeset is needed and leaves the label to the maintainer.
• security — never. It publicly marks a PR as a security fix before a release carries it and hints at the vector. A security fix is labelled by area only (topic: *, feat: *); maintainers add security afterwards if they choose.
• AI assisted — the author's (or a maintainer's) call, not a reviewer's. It marks PRs containing AI-generated content. The author adds it to their own PR, and an agent working for the author applies it when the author says so; maintainers may add it as well. If you notice AI-generated content in a PR you did not author, mention it in your report; do not label it.

4. Choosing — worked examples from the history

• perf(6.x): stop re-compressing tarballs… → performance + 6.x branch (latest).
• feat: staged publishing and 2FA → dev: experiment + 7.x branch (next).
• fix(search): include license in local results → topic: search + 7.x branch (next).
• fix(logger): honor JSON sync… → issue: bug + topic: logging + 7.x branch (next).
• fix: emit tarball content-length before data flows → issue: bug + feat: storage + plugin: local-storage + 7.x branch (next).
• fix: tarball download reliability — uplink selection… (large, multi-topic) → issue: bug + feat: storage + topic: proxy/uplinks + performance + 7.x branch (next).
• chore: migrate pnpm to v12 → dev: migration + 7.x branch (next) (+ skip changeset, added by a maintainer).
• Workflow-only change → dev: ci-build + the release line.

Rule of thumb: a perf(...) title takes performance; anything touching uplinks, remote tarballs, or the proxy takes topic: proxy/uplinks; a storage-layer change takes feat: storage and the plugin label when a bundled plugin changed; UI work takes topic: web and React when components changed.

5. When reviewing someone else's PR

Missing or wrong labels are a review finding, reported like any other. Fix them yourself only when the task asked you to maintain the PR; otherwise name the labels it should carry.