Why does a Playwright run with --project=admin-console --no-deps fail when the same command without the flag passes?

## What the flag means `--no-deps` is a command-line switch for `playwright test`: it tells the runner to execute the projects you asked for and **not** the projects those list in their `dependencies` array. Without it, naming a project with `--project` also pulls in its whole dependency subgraph, which is normally what you want -- that is the point of declaring the dependency. With it, you are explicitly saying "the preconditions are already satisfied, do not redo them". ## Why the run then fails The failure is a missing precondition, not a broken test. A project that depends on a setup project is written on the assumption that the setup project just ran in this invocation. Skip it and whatever it was supposed to leave behind is either absent or left over from an earlier run: - The artefact the setup project writes to disk does not exist yet, so the first test that reads it throws during setup rather than failing an assertion. - The artefact exists but is stale, so tests fail in confusing, partial ways instead of failing at once. - The environment the setup project shapes -- feature flags on the internal admin console, a seeded staff role, an enabled module -- is in whatever state the last run left it in. The tell is that the failure moves: with `--no-deps` the suite breaks early and identically on every run, and adding the setup project back makes it green without touching any test code. ## When using it is correct 1. **Tight local iteration.** Run the setup project once, then loop on one test project with `--no-deps` while you edit a spec. Each iteration saves the entire preparation phase. 2. **A precondition owned outside the run.** If a pipeline stage or a shared environment already prepared what the suite needs, re-running the setup project would only duplicate it. 3. **Debugging the split itself** -- proving which state a project actually depends on by removing the step that provides it and watching what breaks. ## When it is a trap - **In CI.** A pipeline that runs projects with `--no-deps` to save time is depending on state left by a previous, unrelated run. It passes until the runner is replaced or a job runs on a clean machine. - **After changing the setup project.** The change simply does not take effect, and you debug the wrong file. - **As a fix for a slow suite.** The preparation phase is slow for a reason; hiding it makes runs unreproducible instead of faster. ## How to keep the escape hatch honest | Habit | Effect | |---|---| | Make setup steps idempotent | Re-running the graph is cheap, so `--no-deps` is a convenience, never a necessity | | Fail fast on missing precondition state | The error names what is missing instead of surfacing as a strange assertion failure | | Keep `--no-deps` out of pipeline commands | CI always executes the full graph and stays reproducible | | Split one setup project into narrow ones | Each project waits only for what it lists, so the full graph is fast enough to keep running | The flag is a local speed tool built on a promise you are making by hand. Playwright cannot verify the promise, which is why the same command is excellent at a developer's keyboard and a liability in a pipeline. ## Telling it apart from real flakiness The two failure shapes look similar in a terminal and are easy to confuse, so compare them deliberately: - A skipped precondition fails on **every** run, at the **same** point, and usually during a setup step rather than inside an assertion. - Genuine flakiness fails intermittently, at varying points, and often passes on retry. - The decisive experiment is one command: re-run without `--no-deps`. Green means the precondition was the cause and no test code needs changing.