chore(deps): raise react-router-dom peer floor past security advisory#104
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Raise the
react-router-domv7 peer floor from^7.0.0to^7.15.1to steer adopters past a high-severity advisory, and refresh the lockfile so this repo's own install uses the fixed version.The advisory
react-router7.0.0 through 7.15.0 has a high-severity issue in its vendored turbo-stream (arbitrary constructor invocation via deserialization). Our peer range^7.0.0permitted the entire vulnerable band with no floor. React Router 6 is unaffected, so^6.4.0is unchanged.^6.4.0 || ^7.0.0->^6.4.0 || ^7.15.1react-router7.13.0 -> 7.18.1npm auditno longer reports react-router. The suite passes on 7.18.1 (the SDK uses only stable declarative APIs:useNavigate,useHref,useSearchParams,Routes,Route,MemoryRouter), and the packed output is unchanged.Why a peer bump rather than a pin
react-router-domis a peer dependency, so adopters resolve their own copy and the SDK cannot pin it for them. Raising the floor is the available lever: npm warns an adopter still on a vulnerable v7 until they move to 7.15.1 or later. The lockfile change only affects this repo's CI and dev install.Separate finding, not fixed here
While tracing the audit I found a residual moderate (
js-yaml) in the production dependency tree, reachable througheslint-plugin-license-header->eslint->js-yaml. The root cause is thateslint-plugin-license-headerandts-nodeare declared independenciesrather thandevDependencies. They are lint and build tooling, so they should not be runtime dependencies: today every adopter installs the full eslint toolchain (and its vulnerable js-yaml) transitively for no reason.That is a
dependenciesreorganization rather than a security patch bump, and it wants its own verification (confirm nothing in the build path needs them at runtime), so I kept it out of this PR. Worth a focused follow-up. Flagging rather than filing per the current workflow.Checks
npm run typecheck,npm run lint,npm run format:checkcleannpm auditno longer reports react-routernpm run check-npm-build: packed output unchanged