Fix qs module resolution in an npm workspaces monorepo after a Renovate dependency bump

What they did

A Renovate PR bumped qs to ^6.17.0, but the library workspace test run failed with "Cannot find module 'qs'". The author traced the failure to co-body (pulled in via @web/test-runner-core), which needs qs at runtime but could no longer resolve it because the lockfile update dropped the install path that test dependency chain relied on. Rather than loosening or skipping tests, they fixed the cause in three coordinated edits: added qs ^6.17.0 to packages/realtime-bpm-analyzer devDependencies so the library test toolchain has an explicit provider instead of depending on incidental root lockfile state; updated the root overrides.qs to ^6.17.0 to keep the repo-wide forced version aligned with the Renovate bump; and corrected package-lock.json so node_modules/qs is present and resolved at 6.17.1, with the library workspace recording qs in its dev dependency set. The change was kept as small as possible and done in the same PR so the original Renovate PR could be closed.

How it went

CI went green with the qs bump in place. The fix is a small, targeted three-file change (workspace package.json, root package.json overrides, lockfile) that addresses the resolution cause rather than the symptom. No tests were loosened, skipped, or deleted, and no new dependency was introduced beyond the one already being bumped.

Worth knowing

The post does not show the actual CI run output or confirm every job passed, only that the module resolution issue was addressed. The exact hoisting behavior of npm workspaces that caused the dropped install path is described but not deeply explained. No regression test was added for the resolution itself, since it is a toolchain concern rather than library behavior.

Wiring

Order of operations: (1) reproduce the failure by running npm test in packages/realtime-bpm-analyzer and reading the Cannot find module 'qs' stack to confirm co-body via @web/test-runner-core is the consumer; (2) inspect the root package-lock.json to see that the qs install path was dropped; (3) add "qs": "^6.17.0" to packages/realtime-bpm-analyzer devDependencies alongside music-metadata and ts-node; (4) set root package.json overrides.qs to ^6.17.0 so the forced version matches the Renovate bump; (5) regenerate package-lock.json so node_modules/qs is present at 6.17.1 and the library workspace records qs in its dev dependency set; (6) rerun the library workspace tests and the full CI to confirm green.

Try it yourself

In this npm workspaces monorepo, a Renovate PR bumped qs to ^6.17.0 but the library workspace test run fails with "Cannot find module 'qs'". Find where qs is used (likely a test helper or dev server via co-body and @web/test-runner-core), determine why it no longer resolves after the bump (workspace hoisting, lockfile state, or a dependency declared in the wrong package.json), and fix the cause so CI is green. Do the qs update in this PR itself, starting from main. Keep the change as small as works: add qs to the library workspace devDependencies, align the root overrides.qs, and correct package-lock.json so node_modules/qs resolves at the bumped version. Do not loosen, skip, or delete tests. Use conventional commit messages that explain why, avoid feat: and breaking markers, and write no em or en dashes anywhere.