Update dependency react-router to v6 [SECURITY]#3186
Update dependency react-router to v6 [SECURITY]#3186renovate[bot] wants to merge 1 commit intomainfrom
Conversation
OpenAPI ChangesShow/hide ## Changes for v0.yaml:Unexpected changes? Ensure your branch is up-to-date with |
renovate
bot
force-pushed
the
renovate/npm-react-router-vulnerability
branch
29 times, most recently
from
8ae9517 to
301443b
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The upgrade to react-router@6 will cause a startup crash because the code imports APIs like Router, Switch, and withRouter that no longer exist in that version.
Severity: CRITICAL
Suggested Fix
To fix this, either revert the react-router upgrade or complete the migration to React Router v6. A full migration involves upgrading react-router-dom as well and refactoring the code to use v6 APIs, such as replacing Switch with <Routes> and using hooks like useNavigate instead of the history prop.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The project upgrades `react-router` to v6.30.2 but the codebase
continues to import components and HOCs like `Router`, `Route`, `Switch`, and
`withRouter` from it. These APIs were removed in React Router v6. Consequently, these
imports will fail at module load time, preventing the JavaScript bundle from being
created or loaded correctly. This will cause the entire frontend application to fail on
startup. The upgrade is incomplete, as it also fails to update `react-router-dom` or
refactor the code to use the new v6 APIs.
| "react-router": "6.30.2", | ||
| "react-router-dom": "4.3.1", |
There was a problem hiding this comment.
Bug: Upgrading react-router to v6 while leaving react-router-dom on v4 will cause conflicting dependencies and break routing at runtime.
Severity: CRITICAL
Suggested Fix
To resolve the version conflict, either upgrade react-router-dom to a compatible v6 version (e.g., 6.3.0) to match the new react-router version, or downgrade react-router back to 4.3.1 to match react-router-dom. Both packages should be on the same major version.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95-L96
Potential issue: The pull request upgrades `react-router` to version `6.30.2` but leaves
`react-router-dom` at `4.3.1`. Since `react-router-dom@4.3.1` has a dependency on
`react-router@^4.3.1`, this results in two different major versions of `react-router`
being installed simultaneously. This creates two separate and incompatible routing
contexts within the application. Components relying on `react-router-dom` (using a v4
context) will not receive navigation updates or share state with components using the
newer `react-router` (v6 context), leading to broken navigation and unpredictable
routing behavior at runtime.
| "react-router": "6.30.2", | ||
| "react-router-dom": "4.3.1", |
There was a problem hiding this comment.
Bug: This PR updates react-router to v6 while leaving react-router-dom at v4. The application's v4-based routing code is incompatible with the v6 library, which will cause crashes.
Severity: CRITICAL
Suggested Fix
To resolve this, either revert the react-router update to maintain version consistency with react-router-dom, or perform a complete migration. A full migration would involve updating react-router-dom to v6 and refactoring all application code to use the new v6 APIs, such as replacing <Switch> with <Routes>.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95-L96
Potential issue: The pull request updates the `react-router` package to version 6, while
`react-router-dom` remains at version 4. The application's codebase heavily relies on
`react-router` v4 APIs, such as the `<Switch>` component, the `component` prop on
`<Route>`, and passing a `history` prop to `<Router>`. These APIs were removed or
changed in `react-router` v6. This direct version incompatibility will cause the
application to fail immediately upon rendering or attempting to navigate, as the
existing v4-based code cannot function with the v6 library.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The code passes a history prop to the <ReactRouter> component, but this prop is no longer supported in react-router v6 and will be ignored.
Severity: HIGH
Suggested Fix
Remove the creation of the history object using createBrowserHistory and stop passing the history prop to React Router v6 components. Instead, use the built-in history management of React Router v6. This may involve using hooks like useNavigate for programmatic navigation and wrapping the application in a v6-compatible router component like <BrowserRouter>.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The upgrade of `react-router` to v6.30.2 introduces a breaking change.
The code in files like `frontend/public/src/entry/root.js` and
`frontend/public/src/entry/header.js` creates a custom history object using `history@4`
and passes it via a `history` prop to the `<ReactRouter>` component. React Router v6 no
longer supports the `history` prop and manages its own history internally. The passed
prop will be ignored, which will cause routing to behave unexpectedly or fail, as the
application's intended history management is disconnected from the router.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The upgrade to React Router v6 will cause a crash because the withRouter HOC, used in ScrollToTop.js, has been removed from the library.
Severity: CRITICAL
Suggested Fix
Replace the withRouter HOC with React Router v6 hooks. For navigation, use the useNavigate hook. To access location for components like ScrollToTop, use the useLocation hook. Additionally, replace the custom history object and direct history.push() calls with the useNavigate hook for programmatic navigation.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The application upgrades `react-router` to version 6. This version
removes the `withRouter` Higher-Order Component (HOC), which is currently used to wrap
the `ScrollToTop` component. When the application attempts to render this component, it
will fail to find `withRouter`, causing a runtime error that will crash the application
during initialization. This prevents the application from loading correctly. A secondary
issue is that programmatic navigation via `history.push()` will silently fail because
the `history` prop is no longer supported on the `<Router>` component in v6, but this
bug is masked by the more critical startup crash.
| "react-router": "6.30.2", | ||
| "react-router-dom": "4.3.1", |
There was a problem hiding this comment.
Bug: Components expect location, history, and match props from Route, but these are not provided in React Router v6, causing runtime errors when accessed.
Severity: CRITICAL
Suggested Fix
Migrate components to use React Router v6 hooks like useLocation, useNavigate, and useParams to access routing information instead of relying on props passed by Route.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95-L96
Potential issue: The application upgrades `react-router` to version 6 but continues to
use patterns from version 4. Specifically, components rendered by `Route` expect to
receive `location`, `history`, and `match` as props. In React Router v6, these props are
no longer passed to routed components by default. Code that attempts to access these
props, such as `this.props.history.push()`, will fail at runtime because the properties
will be `undefined`, leading to application crashes during navigation or rendering.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: Upgrading react-router to v6 breaks navigation. The history prop is no longer supported, but the code still passes it to <ReactRouter> and uses history.push() for navigation.
Severity: CRITICAL
Suggested Fix
Refactor the application's routing and navigation logic to conform to React Router v6 APIs. This involves removing the history prop from <Router> components and replacing programmatic navigation calls like history.push() with the useNavigate hook or other v6-compatible methods. Ensure that react-router-dom is also upgraded to a compatible version.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The application upgrades `react-router` to v6 but continues to use the
v4/v5 pattern of passing a `history` object to the router component. React Router v6
removed support for the `history` prop, so this will be ignored or cause an error. Core
navigation functionality, which relies on programmatic calls like `history.push()` in
files such as `auth.js`, will break. This will prevent users from navigating through
critical flows like login and registration. The codebase uses `<ReactRouter
history={history}>` in `frontend/public/src/Router.js` and
`frontend/public/src/entry/header.js`, which is incompatible with the new version.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The react-router package is upgraded to v6 while react-router-dom remains on v4. This version mismatch and use of removed v4 APIs will cause the application to crash on startup.
Severity: CRITICAL
Suggested Fix
To resolve the incompatibility, either upgrade react-router-dom to a compatible v6 version and refactor the entire application to use v6 APIs (e.g., replace <Switch> with <Routes>, use hooks like useNavigate and useParams instead of withRouter and injected props), or revert the react-router upgrade to keep both packages on v4.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The PR upgrades `react-router` to v6.30.2 but leaves `react-router-dom`
at v4.3.1. This version mismatch will cause the application to fail. The codebase uses
APIs and patterns from v4 that were removed or changed in v6, such as the `<Switch>`
component, the `withRouter` HOC, and passing a `history` prop to the router component.
Components also rely on router props like `this.props.history` and
`this.props.match.params` which are no longer injected automatically in v6. This
incompatibility will likely cause the application to fail during dependency resolution,
build, or immediately upon startup, preventing it from running.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The upgrade to react-router v6 will cause a runtime crash because withRouter, used in ScrollToTop.js, has been removed in this version.
Severity: CRITICAL
Suggested Fix
Refactor the ScrollToTop.js component to stop using the withRouter HOC. Instead, use the appropriate hooks provided by react-router v6, such as useLocation, to achieve the same functionality.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The application uses the `withRouter` Higher-Order Component from
`react-router` in the `ScrollToTop.js` component. This pull request upgrades
`react-router` to version 6, in which the `withRouter` HOC has been removed. As a
result, attempting to render the `ScrollToTop` component will cause a runtime error,
likely crashing the application, because the imported `withRouter` will be undefined.
The new version of the library favors hooks like `useLocation` and `useNavigate` for
this functionality.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The code uses react-router v4 APIs with the newly upgraded v6 library, which will cause runtime crashes and break all application routing.
Severity: CRITICAL
Suggested Fix
To resolve this, the application's routing implementation must be migrated to react-router v6. This includes replacing <Switch> with <Routes>, updating <Route> props from component to element, and using hooks like useNavigate instead of the history prop and withRouter. Alternatively, revert the react-router package to a v4-compatible version.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The `react-router` package has been upgraded to version 6, but the
application code still uses APIs from version 4. Key incompatibilities include the use
of `<Switch>`, the `withRouter` HOC, and passing a `history` prop to the main router
component. These APIs were removed or significantly changed in `react-router` v6. For
instance, `<Switch>` is replaced by `<Routes>`, and the `history` prop is no longer
supported. This mismatch will cause the application to crash at runtime when attempting
to render any routed components, breaking all navigation.
| languageName: node | ||
| linkType: hard | ||
|
|
||
| "react-router@npm:4.3.1, react-router@npm:^4.3.1": | ||
| "react-router@npm:6.3.0": | ||
| version: 6.3.0 |
There was a problem hiding this comment.
Bug: This change introduces two incompatible versions of react-router (v4 and v6) by not updating react-router-dom concurrently, which will likely break routing due to context conflicts.
Severity: HIGH
Suggested Fix
To resolve the incompatibility, update react-router-dom to a version compatible with react-router v6. Both packages should be on the same major version to ensure a single, consistent routing context is used throughout the application.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: yarn.lock#L19622-L19626
Potential issue: The pull request updates `react-router` to version 6.30.2 but leaves
`react-router-dom` at version 4.3.1. Since `react-router-dom@4.3.1` has a dependency on
`react-router@^4.3.1`, this change causes two incompatible major versions of
`react-router` to be installed simultaneously. The application code contains imports
from both the v6 `react-router` package and the v4 `react-router-dom` package. Because
React Router v4 and v6 use different and incompatible React contexts, components like
`<Link>`, `<Switch>`, and `<Route>` from the v4 package will not work correctly, likely
breaking routing and navigation across the application.
| languageName: node | ||
| linkType: hard | ||
|
|
||
| "react-router@npm:4.3.1, react-router@npm:^4.3.1": | ||
| "react-router@npm:6.3.0": | ||
| version: 6.3.0 |
There was a problem hiding this comment.
Bug: The update to react-router v6 while react-router-dom remains on v4 will cause runtime crashes due to major API incompatibilities between the two versions.
Severity: CRITICAL
Suggested Fix
To resolve the API incompatibilities and prevent runtime crashes, update react-router-dom to a version compatible with react-router v6 (e.g., 6.30.2). After updating, refactor the code to use the new v6 APIs, such as replacing Switch with Routes and removing usages of the history prop and withRouter HOC.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: yarn.lock#L19622-L19626
Potential issue: The application has conflicting versions of `react-router` installed:
v6.30.2 as a direct dependency and v4.3.1 as an indirect dependency from
`react-router-dom@4.3.1`. This mismatch will cause immediate runtime crashes because the
code attempts to use APIs that have been removed or changed in v6. For example, the
`history` prop is passed to `<ReactRouter>`, but this prop was removed in v6. Similarly,
components like `Switch`, `Redirect`, and the `withRouter` HOC are imported and used,
but they do not exist in `react-router` v6, having been replaced by alternatives like
`Routes`.
| "react-router@npm:^4.3.1": | ||
| version: 4.3.1 | ||
| resolution: "react-router@npm:4.3.1" | ||
| dependencies: |
There was a problem hiding this comment.
Bug: Upgrading react-router to v6 without upgrading react-router-dom creates a dependency conflict, causing react-router-dom v4 components to fail at runtime by using incompatible v6 APIs.
Severity: CRITICAL
Suggested Fix
To resolve the incompatibility, react-router-dom should be upgraded to a version compatible with react-router v6, such as 6.30.2. This will ensure both packages use the same API version. The codebase will also need to be migrated to use the new v6 APIs, such as replacing <Switch> with <Routes> and using the element prop on <Route> instead of component.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: yarn.lock#L19647-L19650
Potential issue: The project's direct dependency on `react-router` is upgraded to
version 6.30.2, while the `react-router-dom` dependency remains at version 4.3.1. The v4
`react-router-dom` package has a peer dependency on `react-router` v4. Due to dependency
resolution, `react-router-dom` will be forced to use the installed v6 `react-router`
package. This creates an API mismatch, as v4 components like `Link`, `Route`, and
`Switch` from `react-router-dom` will attempt to call v6 APIs that are incompatible or
no longer exist, causing runtime errors when routing-related components are rendered.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The react-router upgrade to v6 introduces breaking changes. The code still uses the removed <Switch> component and deprecated component prop, which will cause a runtime crash.
Severity: CRITICAL
Suggested Fix
Migrate the routing logic to the react-router v6 API. Replace <Switch> with <Routes>. Update all <Route> elements to use the element prop with JSX (e.g., element={<LoginPages />}) instead of the component prop. Replace usages of the withRouter HOC with corresponding v6 hooks like useNavigate, useParams, and useLocation.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The application upgrades `react-router` from v4.3.1 to v6.30.2 but does
not update the code to match the new API. Specifically, `App.js` imports and uses the
`<Switch>` component, which was removed in v6 and replaced by `<Routes>`. When React
attempts to render the undefined `<Switch>` component, it will throw a `TypeError`,
causing the entire application to crash at runtime. Additionally, all `<Route>`
instances use the `component` prop, which is also removed in v6 and replaced by the
`element` prop. This would cause routes to render nothing, breaking all navigation.
Other removed APIs like `withRouter` are also still in use.
| "react-picky": "4.7.2", | ||
| "react-redux": "^7.1.0", | ||
| "react-router": "4.3.1", | ||
| "react-router": "6.30.2", |
There was a problem hiding this comment.
Bug: The upgrade to react-router v6 is a breaking change. The code still uses removed APIs like withRouter and <Switch>, which will cause a runtime crash on startup.
Severity: CRITICAL
Suggested Fix
Migrate the application's routing logic to be compatible with React Router v6. This involves replacing the <Switch> component with <Routes>, and refactoring components that use the withRouter HOC to instead use hooks like useLocation(), useNavigate(), and useParams().
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: frontend/public/package.json#L95
Potential issue: The update of `react-router` to version 6.30.2 is a breaking change
that is not accompanied by the necessary code migrations. The application code continues
to use APIs that were removed in version 6. Specifically, `ScrollToTop.js` imports and
uses the `withRouter` Higher-Order Component, and `App.js` (among other files) imports
and uses the `<Switch>` component. Both `withRouter` and `<Switch>` are no longer
exported by `react-router` v6. When the application attempts to load these components,
it will try to use these `undefined` imports, resulting in a runtime `TypeError` that
will crash the entire application on startup, preventing it from rendering.
This PR contains the following updates:
4.3.1→6.30.2GitHub Vulnerability Alerts
CVE-2025-68470
An attacker-supplied path can be crafted so that when a React Router application navigates to it via
navigate(),<Link>, orredirect(), the app performs a navigation/redirect to an external URL. This is only an issue if developers pass untrusted content into navigation paths in their application code.Release Notes
remix-run/react-router (react-router)
v6.30.2: v6.30.2Compare Source
See the changelog for release notes: https://github.com/remix-run/react-router/blob/v6/CHANGELOG.md#v6302
v6.30.1: v6.30.1Compare Source
See the changelog for release notes: https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v6301
v6.30.0: v6.30.0Compare Source
See the changelog for release notes: https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v6300
v6.29.0: v6.29.0Compare Source
See the changelog for release notes: https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v6290
v6.28.2: v6.28.2Compare Source
See the changelog for release notes: https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v6282
v6.28.1: v6.28.1Compare Source
See the changelog for release notes: https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v6281
v6.28.0Compare Source
Minor Changes
json/deferin favor of returning raw objectsPatch Changes
@remix-run/router@1.21.0v6.27.0Compare Source
Minor Changes
unstable_patchRoutesOnNavigation(#11973)PatchRoutesOnNavigationFunctionArgstype for convenience (#11967)unstable_dataStrategy(#11974)unstable_flushSyncoption for navigations and fetchers (#11989)unstable_viewTransitionoption for navigations and the correspondingunstable_useViewTransitionStatehook (#11989)Patch Changes
Fix bug when submitting to the current contextual route (parent route with an index child) when an
?indexparam already exists from a prior submission (#12003)Fix
useFormActionbug - when removing?indexparam it would not keep other non-Remixindexparams (#12003)Fix types for
RouteObjectwithinPatchRoutesOnNavigationFunction'spatchmethod so it doesn't expect agnostic route objects passed topatch(#11967)Updated dependencies:
@remix-run/router@1.20.0v6.26.2Compare Source
Patch Changes
@remix-run/router@1.19.2v6.26.1Compare Source
Patch Changes
unstable_patchRoutesOnMisstounstable_patchRoutesOnNavigationto match new behavior (#11888)@remix-run/router@1.19.1v6.26.0Compare Source
Minor Changes
replace(url, init?)alternative toredirect(url, init?)that performs ahistory.replaceStateinstead of ahistory.pushStateon client-side navigation redirects (#11811)Patch Changes
future.v7_partialHydrationalong withunstable_patchRoutesOnMiss(#11838)router.state.matcheswill now include any partial matches so that we can render ancestorHydrateFallbackcomponents@remix-run/router@1.19.0v6.25.1Compare Source
No significant changes to this package were made in this release. See the repo
CHANGELOG.mdfor an overview of all changes in v6.25.1.v6.25.0Compare Source
Minor Changes
future.unstable_skipActionErrorRevalidationasfuture.v7_skipActionErrorRevalidation(#11769)Responsewith a4xx/5xxstatus codeshouldRevalidateshouldRevalidate'sunstable_actionStatusparameter toactionStatusPatch Changes
useMatchso matches/params reflect decoded params (#11789)@remix-run/router@1.18.0v6.24.1Compare Source
Patch Changes
future.v7_relativeSplatPath, properly resolve relative paths in splat routes that are children of pathless routes (#11633)@remix-run/router@1.17.1v6.24.0Compare Source
Minor Changes
unstable_patchRoutesOnMissdocs: https://reactrouter.com/v6/routers/create-browser-routerPatch Changes
@remix-run/router@1.17.0v6.23.1Compare Source
Patch Changes
<Await>(#11513)@remix-run/router@1.16.1v6.23.0Compare Source
Minor Changes
unstable_dataStrategyconfiguration option (#11098)Patch Changes
@remix-run/router@1.16.0v6.22.3Compare Source
Patch Changes
@remix-run/router@1.15.3v6.22.2Compare Source
Patch Changes
@remix-run/router@1.15.2v6.22.1Compare Source
Patch Changes
@remix-run/router@1.15.1v6.22.0Compare Source
Patch Changes
@remix-run/router@1.15.0v6.21.3Compare Source
Patch Changes
unstable_prefix fromBlocker/BlockerFunctiontypes (#11187)v6.21.2Compare Source
Patch Changes
@remix-run/router@1.14.2v6.21.1Compare Source
Patch Changes
route.lazynot working correctly on initial SPA load whenv7_partialHydrationis specified (#11121)@remix-run/router@1.14.1v6.21.0Compare Source
Minor Changes
Add a new
future.v7_relativeSplatPathflag to implement a breaking bug fix to relative routing when inside a splat route. (#11087)This fix was originally added in #10983 and was later reverted in #11078 because it was determined that a large number of existing applications were relying on the buggy behavior (see #11052)
The Bug
The buggy behavior is that without this flag, the default behavior when resolving relative paths is to ignore any splat (
*) portion of the current route path.The Background
This decision was originally made thinking that it would make the concept of nested different sections of your apps in
<Routes>easier if relative routing would replace the current splat:Any paths like
/dashboard,/dashboard/team,/dashboard/projectswill match theDashboardroute. The dashboard component itself can then render nested<Routes>:Now, all links and route paths are relative to the router above them. This makes code splitting and compartmentalizing your app really easy. You could render the
Dashboardas its own independent app, or embed it into your large app without making any changes to it.The Problem
The problem is that this concept of ignoring part of a path breaks a lot of other assumptions in React Router - namely that
"."always means the current location pathname for that route. When we ignore the splat portion, we start getting invalid paths when using".":We've also introduced an issue that we can no longer move our
DashboardTeamcomponent around our route hierarchy easily - since it behaves differently if we're underneath a non-splat route, such as/dashboard/:widget. Now, our"."links will, properly point to ourself inclusive of the dynamic param value so behavior will break from it's corresponding usage in a/dashboard/*route.Even worse, consider a nested splat route configuration:
Now, a
<Link to=".">and a<Link to="..">inside theDashboardcomponent go to the same place! That is definitely not correct!Another common issue arose in Data Routers (and Remix) where any
<Form>should post to it's own routeactionif you the user doesn't specify a form action:This is just a compounded issue from the above because the default location for a
Formto submit to is itself (".") - and if we ignore the splat portion, that now resolves to the parent route.The Solution
If you are leveraging this behavior, it's recommended to enable the future flag, move your splat to it's own route, and leverage
../for any links to "sibling" pages:This way,
.means "the full current pathname for my route" in all cases (including static, dynamic, and splat routes) and..always means "my parents pathname".Patch Changes
@remix-run/router@1.14.0v6.20.1Compare Source
Patch Changes
useResolvedPathfix for splat routes due to a large number of applications that were relying on the buggy behavior (see #11052 (comment)). We plan to re-introduce this fix behind a future flag in the next minor version. (#11078)@remix-run/router@1.13.1v6.20.0Compare Source
Minor Changes
PathParamtype from the public API (#10719)Patch Changes
resolveToin splat routes (#11045)getPathContributingMatchesUNSAFE_getPathContributingMatchesexport from@remix-run/routersince we no longer need this in thereact-router/react-router-domlayers@remix-run/router@1.13.0v6.19.0Compare Source
Minor Changes
unstable_flushSyncoption touseNavigate/useSumbit/fetcher.load/fetcher.submitto opt-out ofReact.startTransitionand intoReactDOM.flushSyncfor state updates (#11005)unstable_prefix from theuseBlockerhook as it's been in use for enough time that we are confident in the API. We do not plan to remove the prefix fromunstable_usePromptdue to differences in how browsers handlewindow.confirmthat prevent React Router from guaranteeing consistent/correct behavior. (#10991)Patch Changes
Fix
useActionDataso it returns proper contextual action data and not any action data in the tree (#11023)Fix bug in
useResolvedPaththat would causeuseResolvedPath(".")in a splat route to lose the splat portion of the URL path. (#10983)"."paths inside a splat route which incorrectly dropped the splat portion of the URL. If you are relative routing via"."inside a splat route in your application you should double check that your logic is not relying on this buggy behavior and update accordingly.Updated dependencies:
@remix-run/router@1.12.0v6.18.0Compare Source
Patch Changes
futureprop onBrowserRouter,HashRouterandMemoryRouterso that it accepts aPartial<FutureConfig>instead of requiring all flags to be included. (#10962)@remix-run/router@1.11.0v6.17.0Compare Source
Patch Changes
RouterProviderfutureprop type to be aPartial<FutureConfig>so that not all flags must be specified (#10900)@remix-run/router@1.10.0v6.16.0Compare Source
Minor Changes
anywithunknownon exposed typings for user-provided data. To do this in Remix v2 without introducing breaking changes in React Router v6, we have added generics to a number of shared types. These continue to default toanyin React Router and are overridden withunknownin Remix. In React Router v7 we plan to move these tounknownas a breaking change. (#10843)Locationnow accepts a generic for thelocation.statevalueActionFunctionArgs/ActionFunction/LoaderFunctionArgs/LoaderFunctionnow accept a generic for thecontextparameter (only used in SSR usages viacreateStaticHandler)useMatches(now exported asUIMatch) accepts generics formatch.dataandmatch.handle- both of which were already set tounknown@privateclass exportErrorResponseto anUNSAFE_ErrorResponseImplexport since it is an implementation detail and there should be no construction ofErrorResponseinstances in userland. This frees us up to export atype ErrorResponsewhich correlates to an instance of the class viaInstanceType. Userland code should only ever be usingErrorResponseas a type and should be type-narrowing viaisRouteErrorResponse. (#10811)ShouldRevalidateFunctionArgsinterface (#10797)_isFetchActionRedirect,_hasFetcherDoneAnything) (#10715)Patch Changes
@remix-run/router@1.9.0v6.15.0Compare Source
Minor Changes
redirectDocument()function which allows users to specify that a redirect from aloader/actionshould trigger a document reload (viawindow.location) instead of attempting to navigate to the redirected location via React Router (#10705)Patch Changes
useRevalidatoris referentially stable across re-renders if revalidations are not actively occurring (#10707)@remix-run/router@1.8.0v6.14.2Compare Source
Patch Changes
@remix-run/router@1.7.2v6.14.1Compare Source
Patch Changes
unstable_useBlockerwhen used with an unstable blocker function (#10652)@remix-run/router@1.7.1v6.14.0Compare Source
Patch Changes
basenamefrom locations provided tounstable_useBlockerfunctions to matchuseLocation(#10573)generatePathwhen passed a numeric0value parameter (#10612)unstable_useBlockerkey issues inStrictMode(#10573)tsc --skipLibCheck:falseissues on React 17 (#10622)typescriptto 5.1 (#10581)@remix-run/router@1.7.0v6.13.0Compare Source
Minor Changes
Move
React.startTransitionusage behind a future flag to avoid issues with existing incompatibleSuspenseusages. We recommend folks adopting this flag to be better compatible with React concurrent mode, but if you run into issues you can continue without the use ofstartTransitionuntil v7. Issues usually boils down to creating net-new promises during the render cycle, so if you run into issues you should either lift your promise creation out of the render cycle or put it behind auseMemo. (#10596)Existing behavior will no longer include
React.startTransition:If you wish to enable
React.startTransition, pass the future flag to your component:Patch Changes
React.startTransitionminification bug in production mode (#10588)v6.12.1Compare Source
Patch Changes
React.startTransitionto fix webpack + react 17 compilation error (#10569)v6.12.0Compare Source
Minor Changes
React.startTransitionif it exists (#10438)Patch Changes
@remix-run/router@1.6.3v6.11.2Compare Source
Patch Changes
basenameduplication in descendant<Routes>inside a<RouterProvider>(#10492)@remix-run/router@1.6.2v6.11.1Compare Source
Patch Changes
ComponentAPI within descendant<Routes>(#10434)useNavigatefrom<Routes>inside a<RouterProvider>(#10432)<Navigate>in strict mode when using a data router (#10435)@remix-run/router@1.6.1v6.11.0Compare Source
Patch Changes
<Routes>whenRouterProvidererrors existed (#10374)Componentinstead ofelementon a route definition (#10287)useNavigatein the render cycle by setting theactiveRefin a layout effect, allowing thenavigatefunction to be passed to child components and called in auseEffectthere. (#10394)useSyncExternalStoretouseStatefor internal@remix-run/routerrouter state syncing in<RouterProvider>. We found some subtle bugs where router state updates got propagated before other normaluseStateupdates, which could lead to footguns inuseEffectcalls. (#10377, #10409)useRevalidator()to resolve a loader-driven error boundary scenario (#10369)RouterProvider,useNavigate/useSubmit/fetcher.submitare now stable across location changes, since we can handle relative routing via the@remix-run/routerinstance and get rid of our dependence onuseLocation(). When usingBrowserRouter, these hooks remain unstable across location changes because they still rely onuseLocation(). (#10336)@remix-run/router@1.6.0v6.10.0Compare Source
Minor Changes
future.v7_normalizeFormMethodwhich will normalize the exposeduseNavigation()/useFetcher()formMethodfields as uppercase HTTP methods to align with thefetch()behavior. (#10207)future.v7_normalizeFormMethod === false(default v6 behavior),useNavigation().formMethodis lowercaseuseFetcher().formMethodis lowercasefuture.v7_normalizeFormMethod === true:useNavigation().formMethodis uppercaseuseFetcher().formMethodis uppercasePatch Changes
createRoutesFromElements(#10193)@remix-run/router@1.5.0v6.9.0Compare Source
Minor Changes
React Router now supports an alternative way to define your route
elementanderrorElementfields as React Components instead of React Elements. You can instead pass a React Component to the newComponentandErrorBoundaryfields if you choose. There is no functional difference between the two, so use whichever approach you prefer 😀. You shouldn't be defining both, but if you doComponent/ErrorBoundarywill "win". (#10045)Example JSON Syntax
Example JSX Syntax
Introducing Lazy Route Modules! (#10045)
In order to keep your application bundles small and support code-splitting of your routes, we've introduced a new
lazy()route property. This is an async function that resolves the non-route-matching portions of your route definition (loader,action,element/Component,errorElement/ErrorBoundary,shouldRevalidate,handle).Lazy routes are resolved on initial load and during the
loadingorsubmittingphase of a navigation or fetcher call. You cannot lazily define route-matching properties (path,index,children) since we only execute your lazy route functions after we've matched known routes.Your
lazyfunctions will typically return the result of a dynamic import.Then in your lazy route modules, export the properties you want defined for the route:
An example of this in action can be found in the
examples/lazy-loading-router-providerdirectory of the repository.🙌 Huge thanks to @rossipedia for the Initial Proposal and POC Implementation.
Updated dependencies:
@remix-run/router@1.4.0Patch Changes
generatePathincorrectly applying parameters in some cases (#10078)v6.8.2Compare Source
Patch Changes
@remix-run/router@1.3.3v6.8.1Compare Source
Patch Changes
@remix-run/router@1.3.2v6.8.0Compare Source
Patch Changes
@remix-run/router@1.3.1v6.7.0Compare Source
Minor Changes
unstable_useBlockerhook for blocking navigations within the app's location origin (#9709)Patch Changes
generatePathwhen optional params are present (#9764)<Await>to acceptReactNodeas children function return result (#9896)@remix-run/router@1.3.0v6.6.2Compare Source
Patch Changes
useIdconsistency during SSR (#9805)v6.6.1Compare Source
Patch Changes
@remix-run/router@1.2.1v6.6.0Compare Source
Patch Changes
useLoaderDatausage inerrorElement(#9735)@remix-run/router@1.2.0v6.5.0Compare Source
This release introduces support for Optional Route Segments. Now, adding a
?to the end of any path segment will make that entire segment optional. This works for both static segments and dynamic parameters.Optional Params Examples
<Route path=":lang?/about>will match:/:lang/about/about<Route path="/multistep/:widget1?/widget2?/widget3?">will match:/multistep/multistep/:widget1/multistep/:widget1/:widget2/multistep/:widget1/:widget2/:widget3Optional Static Segment Example
<Route path="/home?">will match://home<Route path="/fr?/about">will match:/about/fr/aboutMinor Changes
Patch Changes
<Route path="prefix-:param">, to align with how splat parameters work. If you were previously relying on this behavior then it's recommended to extract the static portion of the path at theuseParamscall site: (#9506)@remix-run/router@1.1.0v6.4.5Compare Source
Patch Changes
@remix-run/router@1.0.5v6.4.4Compare Source
Patch Changes
@remix-run/router@1.0.4v6.4.3Compare Source
Patch Changes
useRoutesshould be able to returnnullwhen passinglocationArg(#9485)initialEntriestype increateMemoryRouter(#9498)@remix-run/router@1.0.3v6.4.2Compare Source
Patch Changes
IndexRouteObjectandNonIndexRouteObjecttypes to makehasErrorElementoptional (#9394)RouteObject/RoutePropstypes to surface the error in TypeScript. (#9366)@remix-run/router@1.0.2v6.4.1Compare Source
Patch Changes
initialEntries(#9288)@remix-run/router@1.0.1v6.4.0Compare Source
Whoa this is a big one!
6.4.0brings all the data loading and mutation APIs over from Remix. Here's a quick high level overview, but it's recommended you go check out the docs, especially the feature overview and the tutorial.New APIs
createMemoryRouter<RouterProvider>loaderand mutate with a RouteactionerrorElementdeferandAwaitBug Fixes
useLocationreturns the scoped location inside a<Routes location>component (#9094)Updated Dependencies
@remix-run/router@1.0.0v6.3.0: react-router@v6.3.0Compare Source
What's Changed
New Contributors
Full Changelog: remix-run/react-router@v6.2.2...v6.3.0
v6.2.2Compare Source
What's Changed
🐛 Bug Fixes
New Contributors
Full Changelog: remix-run/react-router@v6.2.1...v6.2.2
v6.2.1Compare Source
This release updates the internal
historydependency to5.2.0.Full Changelog: remix-run/react-router@v6.2.0...v6.2.1
v6.2.0Compare Source
🐛 Bug fixes
RoutePropselementtype, which should be aReactNode([#8473](https://redirect.github.com/remix-ruConfiguration
📅 Schedule: Branch creation - "" in timezone US/Eastern, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.