script/bootstrap and the dependency install in the Dockerfile's build stages. While yarn links dependencies it prints "warning Workspaces can only be enabled in private projects." about twenty times per install. The root package.json is already "private": true, so the warning comes from a dependency's own package.json, not from this repo's.
What happens
Every install and every gate run prints the warning. It changes nothing in the build, but it is noise in every log, and a new warning that matters is easy to miss among it.
What should happen
An install prints no warning that nobody acts on: the warning's source is found, and it is either removed (for example by a resolution or a dependency update, pinned by hash as REPO_POLICIES.md requires) or, if it cannot be, the reason is recorded where the install runs.
Severity: minor (build output only)
Definition of done
The dependency that causes the warning is named in the PR.
The warning is gone from script/bootstrap and the gate, or a one-line comment beside the install says why it stays.
Model: opus-5-5
Seen by the worker on https://git.eeqj.de/sneak/AutistMask/pulls/587.
## Where
`script/bootstrap` and the dependency install in the Dockerfile's build stages. While yarn links dependencies it prints "warning Workspaces can only be enabled in private projects." about twenty times per install. The root `package.json` is already `"private": true`, so the warning comes from a dependency's own `package.json`, not from this repo's.
## What happens
Every install and every gate run prints the warning. It changes nothing in the build, but it is noise in every log, and a new warning that matters is easy to miss among it.
## What should happen
An install prints no warning that nobody acts on: the warning's source is found, and it is either removed (for example by a resolution or a dependency update, pinned by hash as `REPO_POLICIES.md` requires) or, if it cannot be, the reason is recorded where the install runs.
Severity: minor (build output only)
## Definition of done
- [ ] The dependency that causes the warning is named in the PR.
- [ ] The warning is gone from `script/bootstrap` and the gate, or a one-line comment beside the install says why it stays.
Model: opus-5-5
clawbot
self-assigned this 2026-10-19 06:33:12 +02:00
Plan: one PR to next. Find which dependency's package.json declares workspaces without "private": true (the install log and node_modules show it), and name it in the PR. If a dependency update or a resolutions entry removes it, take that, pinned as REPO_POLICIES.md requires, with yarn.lock updated through the install. If nothing removes it, add a one-line comment beside the install in script/bootstrap and the Dockerfile saying which dependency prints it and why it stays. Silencing all yarn warnings is not acceptable.
Model: opus-5-5
Plan: one PR to `next`. Find which dependency's `package.json` declares `workspaces` without `"private": true` (the install log and `node_modules` show it), and name it in the PR. If a dependency update or a `resolutions` entry removes it, take that, pinned as `REPO_POLICIES.md` requires, with `yarn.lock` updated through the install. If nothing removes it, add a one-line comment beside the install in `script/bootstrap` and the Dockerfile saying which dependency prints it and why it stays. Silencing all yarn warnings is not acceptable.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Seen by the worker on #587.
Where
script/bootstrapand the dependency install in the Dockerfile's build stages. While yarn links dependencies it prints "warning Workspaces can only be enabled in private projects." about twenty times per install. The rootpackage.jsonis already"private": true, so the warning comes from a dependency's ownpackage.json, not from this repo's.What happens
Every install and every gate run prints the warning. It changes nothing in the build, but it is noise in every log, and a new warning that matters is easy to miss among it.
What should happen
An install prints no warning that nobody acts on: the warning's source is found, and it is either removed (for example by a resolution or a dependency update, pinned by hash as
REPO_POLICIES.mdrequires) or, if it cannot be, the reason is recorded where the install runs.Severity: minor (build output only)
Definition of done
script/bootstrapand the gate, or a one-line comment beside the install says why it stays.Model: opus-5-5
Plan: one PR to
next. Find which dependency'spackage.jsondeclaresworkspaceswithout"private": true(the install log andnode_modulesshow it), and name it in the PR. If a dependency update or aresolutionsentry removes it, take that, pinned asREPO_POLICIES.mdrequires, withyarn.lockupdated through the install. If nothing removes it, add a one-line comment beside the install inscript/bootstrapand the Dockerfile saying which dependency prints it and why it stays. Silencing all yarn warnings is not acceptable.Model: opus-5-5