Why does a Cypress component spec matched by `e2e.specPattern` vanish from the component run?

## Two spec patterns over one project tree A Cypress project discovers specs from a **per-testing-type** `specPattern`, and the two defaults deliberately overlap: | Testing type | Default `specPattern` | Shape | |---|---|---| | e2e | `cypress/e2e/**/*.cy.{js,jsx,ts,tsx}` | one directory | | component | `**/*.cy.{js,jsx,ts,tsx}` | the whole project | The component default has to be project-wide, because component specs are conventionally kept beside the components they render, anywhere under `src/`. But that pattern also matches every e2e spec under `cypress/e2e`. Left alone, an admin console's tenant-settings e2e specs would be discovered as component specs and fail on the first `cy.visit()`. ## The subtraction, and its direction Cypress resolves this by folding the `e2e` block's `specPattern` into the **ignore list of a component run**. Any file the e2e pattern claims is removed from component discovery. That is a real resolution step, not a convention. The important property is that it is **one-directional**: - a component run excludes everything matching `e2e.specPattern`; - an e2e run does **not** exclude anything matching `component.specPattern`. So a file claimed by both patterns runs as an e2e spec and is invisible to component testing. With the defaults that is exactly what you want. Once someone edits `e2e.specPattern`, it stops being what anyone wants. ## The failure mode The sequence that produces the bug on a real suite: 1. A team keeps the admin console's e2e specs in `cypress/e2e/tenants/` and its component specs in `src/**/*.cy.tsx`. 2. Someone decides a few e2e specs belong nearer the code they exercise and widens `e2e.specPattern` to include `src/**/*.cy.tsx`, or reaches for a broad pattern such as `**/*.cy.{ts,tsx}` to catch specs in both places. 3. Every component spec under `src/` now matches `e2e.specPattern` and is subtracted from the component run. 4. `cypress run --component` reports a shrunken spec list — or none found at all — with **no error and no warning naming the cause**. The specs still exist, still compile, and still open fine in an editor. Nothing in the output points at `e2e.specPattern`, because from the component run's point of view those files were simply never candidates. ## Diagnosing and preventing it - **Put the two patterns side by side** and ask which files both claim. That single comparison is the whole diagnosis; the answer is always the set of missing specs. - **Keep the namespaces disjoint.** Either separate directories (`cypress/e2e/` versus `src/`), or separate suffixes (`*.e2e.cy.ts` versus `*.ct.cy.tsx`) so the two patterns can never claim the same file however either is edited. - **Do not reach for `excludeSpecPattern` first.** That key is your own explicit ignore list per testing type — `*.hot-update.js` by default for e2e, snapshot directories for component. The e2e subtraction is applied on top of it, so a spec can vanish for a reason your `excludeSpecPattern` does not mention, and adding entries there will not bring it back. - **Change one pattern at a time**, and check both spec lists after each change rather than only the one you were editing. ## The other ignore list, and how the two combine It helps to hold both filters in mind at once, because they arrive from different places and only one of them is yours: | Filter | Where it comes from | Applies to | |---|---|---| | `excludeSpecPattern` | you, per testing type — `*.hot-update.js` for e2e, snapshot directories for component | that testing type | | `e2e.specPattern` as an ignore | Cypress, automatically | a component run only | A component run therefore discovers `component.specPattern`, minus `component.excludeSpecPattern`, minus everything matching `e2e.specPattern`. Only the middle term appears anywhere you wrote it, which is why the missing specs look inexplicable: you can read your own configuration end to end and see nothing that excludes them. ## Why it is worth knowing This is a small mechanic with an outsized cost, because it fails by *omission*. A suite that silently stops running twenty component specs is green, fast, and wrong, and it stays that way until someone notices coverage moving in the wrong direction. Any configuration whose effect is "some tests no longer exist" deserves the same suspicion: check the count, not just the colour.