[Snyk] Fix for 1 vulnerabilities #182

Omrisnyk · 2024-09-10T15:50:17Z

Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.

Snyk changed the following file(s):

large-file/package.json

Vulnerabilities that will be fixed with an upgrade:

	Issue	Score
	Regular Expression Denial of Service (ReDoS) SNYK-JS-PATHTOREGEXP-7925106	67

Release notes

Package name: nise

from nise GitHub release notes

Package name: path-to-regexp

8.0.0 - 2024-09-01
Heads up! This is a fairly large change (again) and I need to apologize in advance. If I foresaw what this version would have ended up being I would not have released version 7. A longer blog post and explanation will be incoming this week, but the pivot has been due to work on Express.js v5 and this will the finalized syntax used in Express moving forward.

Added
- Adds key names to wildcards using *name syntax, aligns with : behavior but using an asterisk instead
Changed
- Removes group suffixes of ?, +, and * - only optional exists moving forward (use wildcards for +, {*foo} for *)
- Parameter names follow JS identifier rules and allow unicode characters
Added
- Parameter names can now be quoted, e.g. :"foo-bar"
- Match accepts an array of values, so the signature is now string | TokenData | Array<string | TokenData>
Removed
- Removes loose mode
- Removes regular expression overrides of parameters
v7.1.0...v8.0.0
7.2.0 - 2024-09-10
Added
- Support array inputs for match and pathToRegexp 3fdd88f
v7.1.0...v7.2.0
7.1.0 - 2024-07-13
Added
- Adds a strict option to detect potential ReDOS issues
Fixed
- Fixes separator to default to suffix + prefix when not specified
- Allows separator to be undefined in TokenData
  - This is only relevant if you are building TokenData manually, previously parse filled it in automatically
Comments
- I highly recommend enabling strict: true and I'm probably releasing a V8 with it enabled by default ASAP as a necessary security mitigation
v7.0.0...v7.1.0
7.0.0 - 2024-06-20
Hi all! There's a few major breaking changes in this release so read carefully.

Breaking changes:
- The function returned by compile only accepts strings as values (i.e. no numbers, use String(value) before compiling a path)
  - For repeated values, when encode !== false, it must be an array of strings
- Parameter names can contain all unicode identifier characters (defined as regex \p{XID_Continue}).
- Modifiers (?, *, +) must be used after a param explicitly wrapped in {}
  - No more implied prefix of / or .
- No support for arrays or regexes as inputs
- The wildcard (standalone *) has been added back and matches Express.js expected behavior
- Removed endsWith option
- Renamed strict: true to trailing: false
- Reserved ;, ,, !, and @ for future use-cases
- Removed tokensToRegexp, tokensToFunction and regexpToFunction in favor of simplifying exports
- Enable a "loose" mode by default, so / can be repeated multiple times in a matched path (i.e. /foo works like //foo, etc)
- encode and decode no longer receive the token as the second parameter
- Removed the ESM + CommonJS dual package in favor of only one CommonJS supported export
- Minimum JS support for ES2020 (previous ES2015)
- Encode defaults to encodeURIComponent and decode defaults to decodeURIComponent
Added:
- Adds encodePath to fix an issue around encode being used for both path and parameters (the path and parameter should be encoded slightly differently)
- Adds loose as an option to support arbitrarily matching the delimiter in paths, e.g. foo/bar and foo///bar should work the same
- Allow encode and decode to be set to false which skips all processing of the parameters input/output
- All remaining methods support TokenData (exported, returned by parse) as input
  - This should be useful if you are programmatically building paths to match or want to avoid parsing multiple times
Requests for feedback:
- Requiring {} is an obvious drawback but I'm seeking feedback on whether it helps make path behavior clearer
  - Related: Removing / and . as implicit prefixes
- Removing array and regex support is to reduce the overall package size for things many users don't need
- Unicode IDs are added to align more closely with browser URLPattern behavior, which uses JS identifiers
v6.2.2...v7.0.0
6.2.2 - 2024-04-07
No API changes. Documentation only release.

Changed
- Fix readme example c7ec332
- Update shield URL e828000
v6.2.1...v6.2.2
6.2.1 - 2022-05-06
Fixed
- Fix invalid matching of :name* parameter (#261) 762bc6b
- Compare delimiter string over regexp 86baef8
Added
- New example in documentation (#256) ae9e576
- Update demo link (#250) 77df638
- Update README encode example b39edd4
v6.2.0...v6.2.1
6.2.0 - 2020-09-29
Added
- Support named capturing groups for RegExps (#225)
Fixed
- Update strict flag documentation (#227)
- Ignore test files when bundling (#220)
6.1.0 - 2019-11-20
6.0.0 - 2019-11-20
5.0.0 - 2019-11-12
4.0.5 - 2019-11-12
4.0.4 - 2019-11-12
4.0.3 - 2019-11-12
4.0.2 - 2019-11-12
4.0.1 - 2019-11-12
4.0.0 - 2019-11-12
3.2.0 - 2019-11-11
3.1.0 - 2019-08-31
3.0.0 - 2019-01-14
2.4.0 - 2018-08-26
2.3.0 - 2018-08-20
2.2.1 - 2018-04-24
2.2.0 - 2018-03-07
2.1.0 - 2017-10-20
2.0.0 - 2017-08-23
1.8.0 - 2019-11-11
1.7.0 - 2016-11-08

from path-to-regexp GitHub release notes

Package name: react-router

6.0.0 - 2021-11-03
React Router v6 is here!

Please go read our blog post for more information on all the great stuff in v6 including notes about how to upgrade from React Router v5 and Reach Router.
6.0.0-beta.8 - 2021-10-22
Remember last week when we said

We anticipate this will be the last beta release before v6 stable next week.

Yeah, about that … 😅

We found and squashed a few high-priority bugs that needed to be addressed first. But it's coming very soon, we promise! In the mean time, here's what you'll get from our eight-est and greatest beta release:

🐛 Bug Fixes
- We fixed a few bugs in useHref that resulted in the incorrect resolved value in cases where a basename is used on the <Router /> component (See #8133 and #8142 for details).
- We also fixed a bug in our path ranking algorithm so that splat routes (routes with a * path value) are now correctly ranked ahead of layout routes.
🗒️ Docs

We've added lots of goodies to our docs and examples, and there's a lot more yet to come. Take a look and see if you find something that makes your work a little easier! We think the lazy loading and custom query parsing examples are particularly cool! 🤓
6.0.0-beta.7 - 2021-10-15
In this release we made a small but significant change to how <Link to=".."> works. This is going to help out a lot if you were trying to use links in a * route.

We have also backed out our blocking/prompt APIs for the stable v6 release. We will revisit this post 6.0 when we have a little more time to get it right.

✨ Features

The major change in this release could also be classified as a bugfix or a breaking change, depending on how you look at it. We essentialy altered the way <Link to=".."> works. See #8086 for the motivation behind this change.

You'll probably want to reread the section in the v5 => v6 migration guide about <Link to> values (it has been updated), but it basically boils down to this: any leading .. segment in a <Link to> value traverses "up" one route and builds upon that route's path instead of just removing one URL segment. This feature really completes the story of relative routes and links.

We could consider this a bugfix, since this is how it was always intended to work in the first place. Without it, you'd have a difficult time linking predictably in * routes because your <a href> would be different depending on the number of segments in the current URL.

The reason this could also be considered a breaking change is that .. now works slightly differently in <Link to> than it would in <a href>. When you have <a href=".."> it operates on the URL pathname, removing one segment of the current URL. However, since many routes really only match a single segment of the URL, there is often no difference between <Link to=".."> and <a href="..">.

💔 Breaking Changes
- We removed useBlocker(), usePrompt(), and <Prompt> for now. We will revisit these post 6.0 when we have more time to get it right. But we don't want it to block (see what I did there) the release of all the other awesome stuff we've got in v6.
🛠 Roadmap

We anticipate this will be the last beta release before v6 stable next week. Please give it a shot and let us know how it goes!

👍 Upgrading

If you're thinking about upgrading to v6, I published a few notes this past week that may help you:
- This note talks about removing <Redirect> elements from any <Switch>es you may have in your v5 app and how you can get better SEO in the process if you're currently relying on client-side redirects.
- This note talks about how to refactor your code to avoid "wrapping" <Route> elements, which won't work in v6.
Both of those posts contain steps you can take today in your v5 app without upgrading to v6.

We are also developing a backwards compat lib that should help some of you upgrade from v5 to v6. We'll post more about this when it's ready.

💻 Installing

Development for v6 has switched from dev to the main branch.

If you'd like to test it out, install from npm:
```
$ npm install history react-router-dom@next
```
6.0.0-beta.6 - 2021-10-07
No big enhancements in this release, just squashing bugs and writing lots of tests! Also, we are hard at work on cranking out examples for v6. See the end of this post for an update on our roadmap between here and v6 stable.

🧰 Examples

We have begun creating some examples for v6 that we hope will help developers make effective use of all the new features we have. So far, we have examples for the following:
- Basic Example – A basic client-side app for v6 showing how to use nested routes, layouts, links, and the new <Outlet> API
- Auth Example – Demonstrates an authentication flow including using the new useNavigate() hook, the <Navigate> element, and location.state
- Search Params Example – Demonstrates how to build a simple search form that uses the new useSearchParams() hook
- SSR Example – A server-rendered app that uses <StaticRouter> on the server and uses a <BrowserRouter> with ReactDOM.hydrate() on the client
Each example includes a button in the README that allows you to instantly launch a running instance on StackBlitz that you can play with. We hope you enjoy exploring!

🐛 Bugfixes
- Make <NavLink> match only whole URL segments instead of pieces. This means that <NavLink to="/home/users"> will still be active at /home/users, but not at /home/users2. See #7523
- Makes "layout routes" (routes with no path) never match unless one of their children do. See #8085
- Fixes a route matching regression with splat routes that was introduced in beta.5. See #8072 and #8109
- Fixes matching a nested splat route. See af7d038
- Provide all parent route params to descendant <Routes>. This reverses a decision that we made in beta.5 to remove them. See #8073
💔 Breaking Changes
- Splats in route paths (*) match only after a / in the URL. This means that <Route path="files*"> will always match as if it were <Route path="files/*">. The router will issue a warning if your route path ends with * but not /*
🛠 Roadmap

We are very close to a stable release! The last big code changes we need to make are:
- Fixing "linking up". Currently a <Link to=".."> operates on the URL pathname. However, this makes it difficult to link to the parent route when you're in a splat route. See #8086. This will be a breaking change.
- We are going to remove useBlocker() and <Prompt> in our initial v6 release, with plans to revisit them and possibly add them back at some point in the future. I still need to write up something here that explains our rationale. This will also be a breaking change.
- We are going to add some animation primitives (see #8008). The <Routes location> prop will be in v6, but it isn't ideal for animation.
💻 Installing

Development for v6 is chugging along on the dev branch.

If you'd like to test it out, install from npm:
```
$ npm install history react-router-dom@next
```
6.0.0-beta.5 - 2021-09-25
This week's release adds some much-needed polish to a few niche features of the router: splat routes (a route that uses a * path) and basenames. It also adds a renderMatches API that completes the story for those of you who may have been using react-router-config in v4 and v5.

🐛 Bugfixes
- A * in a child route path matches after a slash following its parent route path. This fixes some situations where the * was overly greedy (see #7972)
- Resolution of <Link to="."> and useResolvedPath(".") values are fixed in splat routes. Previously these resolved relative to the parent route's path. They now resolve relative to the path of the route that rendered them.
✨ Enhancements

This release makes it easier to work with apps that have multiple entry points. Using the <Router basename> prop allows React Router to be easily deployed on only a portion of a larger site by using a portion of the URL pathname (the "basename") to transparently prefix all route paths and link navigations.

For example, you can deploy one React Router app at the /inbox URL prefix, and another one at the /admin prefix. These base URLs represent two different entry points into your app, each with its own bundles. The rest of your site, including the root / URL could be rendered by something other than React Router, for example by your server framework of choice.

In the bundle for each entry point, simply initialize React Router with the basename of that entry point.
```
<Router basename="/inbox">
 // ...
</Router>
```
Then define your routes and link paths without using the /inbox URL prefix in any of them. The entire app will run relative to that prefix.

Another improvement in this release is the addition of the renderMatches API, which is the complement of matchRoutes. These APIs are both very low-level and should not normally be needed. But they are sometimes nice to use if you are doing your own data loading using the array of matches that you get back from matchRoutes.

matchRoutes and renderMatches are the equivalent of the react-router-config package we shipped in v4 and v5, just built directly into the router instead of in a separate package.

💔 Breaking Changes
- <Routes basename> has moved to <Router basename>. This prop is also available on all router variants (<BrowserRouter>, <HashRouter>, etc.).
- useLocation().pathname no longer includes the basename, if present.
- The basename argument was removed from useRoutes. This reverts the signature to useRoutes(routes, location), same as it was previous to beta.4.
- Descendant <Routes> do not get the params from their parents. This helps a set of <Routes> to be more portable by decoupling it from the params of its parents and makes it easier to know which params will be returned from useParams(). If you were relying on this behavior previously, you'll need to pass along the params manually to the elements rendered by the descendant <Routes>. See this comment for an example of how this is to be done and for a potential workaround if you really need the old behavior.
- match.pathname in a splat route now includes the portion of the pathname matched by the *. This makes the * param behave much more like other dynamic :id-style params.
- Resolution of relative <Link>s in splat routes is changed now because the entire pathname that was matched by that route is now different (see previous bullet). Instead of resolving relative to the portion of the pathname before the *, paths resolve relative to the full pathname that was matched by the route.
💻 Installing

Development for v6 is chugging along on the dev branch.

If you'd like to test it out, install from npm:
```
$ npm install history react-router-dom@next
```
6.0.0-beta.4 - 2021-09-11
Last week we released a lot of nice little bug features, but we did get a little carried away and let a little bug slip through with relative path resolution. Our bad! That nasty lil' guy is squashed in this week's beta. 🐛

And there's more! Let's dive in…

🐛 Bugfixes
- Path resolution for nested relative routes was broken in the last release and should now be fixed. Nested routes construct their pathname based on the location of their parent, not the current location. This is explained in detail under Relative Routes and Links in our advanced guides, and the issue itself in #8004
✨ Enhancements
- We made some enhancements with the Params type which is now generic, so you can add your own types if you know what to expect from functions that return query parameters. (#8019)
// before
let { valid, invalid } = useParams(); // No problems here!

let match = useMatch("profile/:userId");
let userId = match?.params.user; // wrong param, but TS doesn't know that!

// after:
let { valid, invalid } = useParams<"valid" | "key">(); // Property 'invalid' does not exist on type 'Params<"valid" | "key">'

let match = useMatch<"userId">("profile/:userId");
let userId = match?.params.user; // Property 'user' does not exist on type 'Params<"userId">'
- Absolute nested path support
There was quite a bit of discussion in #7335 from people who are using constants to define their route paths. In this style, paths are often written as absolute paths from the root / URL. These constants are then able to be used both in <Route path> definitions as well as <Link to> values. It usually looks something like this:

const USERS_PATH = "/users";
const USERS_INDEX_PATH = ${USERS_PATH}/;
const USER_PROFILE_PATH = ${USERS_PATH}/:id;

function UsersRoutes() {
return (
<Routes>
<Route path={USERS_PATH} element={<UsersLayout />}>
<Route path={USERS_INDEX_PATH} element={<UsersIndex />} />
<Route path={USER_PROFILE_PATH} element={<UserProfile />} />
</Route>
</Routes>
);
}

This style of use is now fully supported in v6. This is great for people who write their apps like this, but it technically could cause some breakage if you were using absolute paths (that start with /) in nested routes in previous betas. To fix this, simply remove the / from the beginning of any route paths that are meant to be relative. React Router will throw an error if you are using absolute paths that don't match their parent route paths. Hopefully this should help you find them if you are upgrading.

If you were using <Route path="/"> to indicate an index route, you can now use the new <Route index> prop to accomplish the same thing. The index prop makes it easy to scan a route config to find the index route. It also provides a guarantee that nobody will ever add children to that route.

Here's the same route config as the one above, but rewritten with relative paths and the index prop:
```
function UsersRoutes() {
 return (
 <Routes>
 <Route path="users" element={<UsersLayout />}>
 <Route index element={<UsersIndex />} />
 <Route path=":id" element={<UserProfile />} />
 </Route>
 </Routes>
 );
}
```
A lot of our work on React Router is about doing the least surprising thing for our users. Allowing absolute paths in nested routes gets us a little closer to that goal!

💔 Breaking Changes
- Removed the ability for nested route paths to begin with a / and not contain the complete path of their parent routes. This was necessary in order to introduce support for absolute paths in nested routes, described in detail above
- Removed the createRoutesFromArray utility function. You can now pass your routes directly to useRoutes or matchRoutes without passing it through createRoutesFromArray first
- Removed the PartialRouteObject type. If you were importing and using this type before, use RouteObject instead, which has been updated to make all properties optional
- The useRoutes API has changed slightly. Instead of passing a basename as the second argument, you should instead pass it as a named property in an object:
// Before
useRoutes([...routes], basename);

// After
useRoutes([...routes], { basename });
- The matchPath function now returns match.pattern instead of match.path, which is a little more descriptive about what it actually is
💻 Installing

Development for v6 is chugging along on the dev branch.

If you'd like to test it out, install from npm:
```
$ npm install history react-router-dom@next
```
6.0.0-beta.3 - 2021-09-03
Loads of goodies for you this week, as well as a few breaking changes for all of you eager beavers who are brave enough to use beta software in production! 🦫

(seriously, thank you all for helping us tighten up our APIs and fix nasty bugs)

💔 Breaking Changes!
- NavLink no longer supports the activeClassName or activeStyle props. Instead, we provide a more powerful API that allows you to pass functions to either the className or style props to conditionally apply values based on the link's active state. While a bit more verbose in some cases, this offers a nicer experience for folks who use utility class-based CSS. (#7194)
// Before
<NavLink className="link" activeClassName="active-link" />
<NavLink style={{ color: "blue" }} activeStyle={{ color: "green" }} />

// After
<NavLink
className={({ isActive }) =>
link ${ isActive ? "active-link" : // Couldn't do this before! "inactive-link" }
}
/>
<NavLink style={({ isActive }) => ({ color: isActive ? "green" : "blue" })} />

Note: You can always abstract over this feature in a custom NavLink if you prefer the old v5 API.
- The useRoutes API has changed slightly. Instead of passing a basename as the second argument, you should instead pass it as a named property in an object:
// Before
useRoutes([...routes], basename);

// After
useRoutes([...routes], { basename });

🐛 Bugfixes
- The basename prop on Routes is treated as case-insensitive (#7997)
- useNavigate previously used the incorrect pathname when called from parent routes when the URL matches one of its children. This fix also applies to useSearchParams (#7880)
✨ Enhancements
- Routes and useRoutes now allow you to override the location, which may be useful when building some modal interfaces and route transition animations. We are working hard to update our docs to include examples for advanced patterns where this might be useful, but in the mean time this also brings Routes closer to feature parity with v5's Switch via the location prop. (#7117)
- Provided new hooks useClickHandler and usePressHandler to make customizing Links a bit easier. (#7998)
 - Please note: with great power comes great responsibility. If you create a custom Link, be sure to render an actual HTML anchor element, otherwise your app will likely be inaccessible without a significant amount of additional work which, I assure you, you don't want to do!
💻 Installing

Development for v6 is chugging along on the dev branch.

If you'd like to test it out, install from npm:
```
$ npm install history react-router-dom@next
```
🙏 Credits

Thanks to @ andrelandgraf, @ dhulme, @ fgatti675, @ hugmanrique, @ MeiKatz, @ chaance and @ mjackson for your contributions!
6.0.0-beta.2 - 2021-08-20
🐛 Bugfixes
- Fixed a bug that broke paths in nested routes
- Adds missing displayName back to <Link /> and <NavLink /> components
✨ Enhancements
- The navigate function now prepends hash and search strings by default:
```
navigate({ search: "?foo=1&bar=2" }); // this works as expected!
navigate({ search: "foo=1&bar=2" }); // this also works!
```
- useParams now returns parameters from nested <Route />s when called in a parent <Route />
💻 Installing

Development for v6 is chugging along on the dev branch.

If you'd like to test it out, install from npm:
```
$ npm install history react-router-dom@next
```
🙏 Credits

Thanks to @ liho98, @ wojtekmaj, @ cravend, @ chaance and @ mjackson for your contributions!

Enjoy!
6.0.0-beta.1 - 2021-08-13
6.0.0-beta.0 - 2020-06-19
6.0.0-alpha.5 - 2020-05-15
6.0.0-alpha.4 - 2020-05-05
6.0.0-alpha.3 - 2020-04-04
6.0.0-alpha.2 - 2020-02-22
6.0.0-alpha.1 - 2020-02-01
6.0.0-alpha.0 - 2020-01-31
5.3.4 - 2022-10-02
5.3.3 - 2022-05-18
5.3.2 - 2022-05-17

The following vulnerabilities are fixed with an upgrade: - https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106

fix: large-file/package.json to reduce vulnerabilities

823d467

The following vulnerabilities are fixed with an upgrade: - https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Snyk] Fix for 1 vulnerabilities #182

[Snyk] Fix for 1 vulnerabilities #182

Omrisnyk commented Sep 10, 2024

🐛 Bug Fixes

🗒️ Docs

✨ Features

💔 Breaking Changes

🛠 Roadmap

👍 Upgrading

💻 Installing

🧰 Examples

🐛 Bugfixes

💔 Breaking Changes

🛠 Roadmap

💻 Installing

🐛 Bugfixes

✨ Enhancements

💔 Breaking Changes

💻 Installing

🐛 Bugfixes

✨ Enhancements

💔 Breaking Changes

💻 Installing

💔 Breaking Changes!

🐛 Bugfixes

✨ Enhancements

💻 Installing

🙏 Credits

🐛 Bugfixes

✨ Enhancements

💻 Installing

🙏 Credits

[Snyk] Fix for 1 vulnerabilities #182

Are you sure you want to change the base?

[Snyk] Fix for 1 vulnerabilities #182

Conversation

Omrisnyk commented Sep 10, 2024

Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.

Snyk changed the following file(s):

Vulnerabilities that will be fixed with an upgrade:

🐛 Bug Fixes

🗒️ Docs

✨ Features

💔 Breaking Changes

🛠 Roadmap

👍 Upgrading

💻 Installing

🧰 Examples

🐛 Bugfixes

💔 Breaking Changes

🛠 Roadmap

💻 Installing

🐛 Bugfixes

✨ Enhancements

💔 Breaking Changes

💻 Installing

🐛 Bugfixes

✨ Enhancements

💔 Breaking Changes

💻 Installing

💔 Breaking Changes!

🐛 Bugfixes

✨ Enhancements

💻 Installing

🙏 Credits

🐛 Bugfixes

✨ Enhancements

💻 Installing

🙏 Credits