fix(deps): update dependency wouter to v3

[renovate[bot]]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
wouter	2.12.1 -> 3.3.1

---

Release Notes

molefrog/wouter (wouter)

### [`v3.3.1`](https://togithub.com/molefrog/wouter/compare/v3.3.0...v3.3.1) [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.3.0...v3.3.1) ### [`v3.3.0`](https://togithub.com/molefrog/wouter/releases/tag/v3.3.0): Route parameters inheritance [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.2.1...v3.3.0) Parameters provided by a `Route` component or received from calling `useParams` now also contain values inherited from parent nested routes. See [#​461](https://togithub.com/molefrog/wouter/issues/461) and [#​409](https://togithub.com/molefrog/wouter/issues/409). Example: ```jsx // given the location is "/blog/1/users/4" {/* calling `useParams()` here will return an object containing `{ page: "blog", id: "4" }` {/* note: duplicate keys are overwritten by the inner-most route */} ``` ### [`v3.2.1`](https://togithub.com/molefrog/wouter/compare/v3.2.0...v3.2.1) [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.2.0...v3.2.1) ### [`v3.2.0`](https://togithub.com/molefrog/wouter/releases/tag/v3.2.0): RegExp paths support [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.1.3...v3.2.0) Thanks to [@​JonahPlusPlus](https://togithub.com/JonahPlusPlus), you can now use regular expressions to define custom route patterns. This can be useful, for example, when you need additional validation of a route parameter. See [#​449](https://togithub.com/molefrog/wouter/issues/449) ```ts // this will only match numeric IDs, e.g. "/101", but not "/abc" \d+)$/}>Hello ``` The example above uses [named capturing groups](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Named_capturing_group) to have `id` available as a route parameter. However, you can also use regular groups and access these parameters via numeric indices: ```ts // Route /[/]([a-z]+)/ // Against "/foo", produces { 0: "foo" } // Route /[/](?[a-z]+)/ // Against "/foo", produces { 0: "foo", name: "foo" } ``` ### [`v3.1.3`](https://togithub.com/molefrog/wouter/compare/v3.1.2...v3.1.3) [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.1.2...v3.1.3) ### [`v3.1.2`](https://togithub.com/molefrog/wouter/compare/v3.1.0...v3.1.2) [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.1.0...v3.1.2) ### [`v3.1.0`](https://togithub.com/molefrog/wouter/releases/tag/v3.1.0): Active links, hash location `href`, automatic `ssrSearch` [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.0.2...v3.1.0) This release brings some small improvements: - `Link` can now accept a function in `className` for applying styles to currently active links. [Read more](https://togithub.com/molefrog/wouter?tab=readme-ov-file#how-do-i-make-a-link-active-for-the-current-route) [#​419](https://togithub.com/molefrog/wouter/issues/419) - In SSR, search string can now be extracted directly from `ssrPath`, e.g. pass `/home?a=b` to `ssrPath` and it will pre-fill `ssrSearch` [#​420](https://togithub.com/molefrog/wouter/issues/420) - Finally, after more than 2 years of waiting, links have proper `href` rendered when used with hash location. Before the fix, a link pointing to `"/#users` was rendered as `` without a hash. This now can be controlled via an `hrefs` function defined on a router, but for built-in `useHashLocation` this is done automatically. See [#​421](https://togithub.com/molefrog/wouter/issues/421) - Minor improvement: use `flatMap()` method to flat child element in a switch. Thanks to [abjfdi](https://togithub.com/abjfdi). See [#​254](https://togithub.com/molefrog/wouter/issues/254) ### [`v3.0.2`](https://togithub.com/molefrog/wouter/compare/v3.0.1...v3.0.2) [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.0.1...v3.0.2) ### [`v3.0.1`](https://togithub.com/molefrog/wouter/releases/tag/v3.0.1): Missing docs on npmjs.org [Compare Source](https://togithub.com/molefrog/wouter/compare/v3.0.0...v3.0.1) - README.md file was not part of `wouter`/`wouter-preact` packages, because of the migration to monorepo in v3. This resulted in missing documentation on [npmjs.org](https://www.npmjs.com/package/wouter). This release fixes that. ### [`v3.0.0`](https://togithub.com/molefrog/wouter/releases/tag/v3.0.0): : Routing "all-inclusive" [Compare Source](https://togithub.com/molefrog/wouter/compare/v2.12.1...v3.0.0) Over the past four months, [@​jeetiss](https://togithub.com/jeetiss) and I ([@​molefrog](https://togithub.com/molefrog)) have been working on the upcoming major release v3. We've carefully listened to your requests on features that you wanted to see in Wouter and used this feedback to design the new version’s architecture and API. But everything comes with a cost, so now, the library is no longer 1.5Kb... it's **2.1Kb**. But it's packed with tons of new features: nested routing, wildcard patterns, `useSearch` compatible with SSR, hash location, memory location, history state, `useParams`, more secure History patching, improved TypeScript types, and more! We have also improved tooling to make the development process faster and more bulletproof: replaced Jest with Vitest, added dozens of new test cases, improved the speed of type linting, and simplified the Preact build by [introducing a monorepo](https://togithub.com/molefrog/wouter/pull/318). Below are some breaking changes that we tried to provide a migration guide for. To start using wouter v3, simply install: > npm i wouter@3.0.0 #### Nested routes Previously, there was a hacky workaround to get nested routing working. You would have to manually inherit the router from the parent and customise the `base` path. This was far from ideal, and it only worked for static paths. Now, nesting is a core feature of wouter and can be enabled on a route via the `nest` prop. When this prop is present, the route matches everything that starts with a given pattern and it creates a nested routing context. All child routes will receive location relative to that pattern. Let's take a look at this example: ```js ``` 1. This first route will be active for all paths that start with `/app`, this is equivalent to having a base path in your app. 2. The second one uses dynamic pattern to match paths like `/app/user/1`, `/app/user/1/anything` and so on. 3. Finally, the inner-most route will only work for paths that look like `/app/users/1/orders`. The match is strict, since that route does not have a `nest` prop and it works as usual. If you call `useLocation()` inside the last route, it will return `/orders` and not `/app/users/1/orders`. This creates a nice isolation and it makes it easier to make changes to parent route without worrying that the rest of the app will stop working. If you need to navigate to a top-level page however, you can use a prefix to refer to an absolute path: ```js Back to Home ``` #### Native `useSearch` hook and history state support `useSearch` hook is now part of the core. This means that you can import it from the main module, and will work with SSR too! ```jsx import { useSearch } from "wouter" // returns "tab=settings&id=1" // the hook for extracting search parameters is coming soon! const searchString = useSearch() {/* SSR! */} ``` The long-awaited support for history state is also available now. ```js import { useLocation } from "wouter" const [location, navigate] = useLocation() navigate("/", { state: { user: 1 } }); // it works with Link and Redirect too! // subscribing to state updates import { useHistoryState } from "wouter/use-browser-location" // this will only re-render when the actual state changes, not the URL const state = useHistoryState() ``` #### Improved pattern matching In this release, we are retiring our homemade route pattern parser in favour of [regexparam](https://togithub.com/lukeed/regexparam), the optimised 394B library for transforming route patterns into regular expressions. Although, this change might break existing apps (please refer to the list of breaking changes below), it unlocks some nice features that would not have been possible to achieve in v2: ```tsx // matches literally anything // use optional wildcards to make the trailing slash optional // Parameter w/ Suffix ``` #### Built-in `useBrowserLocation` and `useHashLocation` hooks In v2, in order to access the low-level location hook you had to import it from `"wouter/use-location"`. The name of this file was confusing for many users, because of another function: ```js // V2 API // returns current location scoped to the parent import { useLocation } from "wouter" // low-level location hook, subscribes to current `location.pathname` // these functions are not the same! import useLocation from "wouter/use-location" ``` Unless you are writing an app that only subscribes to the current location and doesn't use other features such as routes, switches, params, base paths etc., you should use the later one. We have renamed this module to `"wouter/use-browser-location"` and added the second essential hook `"wouter/use-hash-location"` for hash-based routing, so you won't need to reimplement it in your apps every time: ```js import { useHashLocation } from "wouter/use-hash-location" ``` #### `memoryLocation` for testing and in-memory routing The package no longer ships with `"wouter/static-location"` module, since this function wasn't well suited for SSR. Instead, there is now a new high-order hook called [`memoryLocation`](https://togithub.com/molefrog/wouter/issues/355) which can be used for in-memory routing or for testing. ```js import { memoryLocation } from "wouter/memory-location" // in-memory router const { hook } = memoryLocation() // initial path is "/" by default // `static` option makes it immutable, use in testing environments that don't support `location` const { hook, navigate } = memoryLocation({ path: "/dashboard", static: true }) navigate("/users") // nothing happens // `record` option for keeping the navigation history in `history` array const { hook, navigate, history } = memoryLocation({ record: true }) ``` #### Link composition with `asChild` prop One of the notable changes is the behaviour of links that customise existing components or `` elements provided in children. We have thoroughly researched best practises from [Next.js](https://nextjs.org/docs/pages/api-reference/components/link#legacybehavior) and [Radix UI](https://www.radix-ui.com/primitives/docs/guides/composition), and have decided to make link composition more explicit. Now, `Link` will always wrap its children in an `` tag, unless `asChild` prop is provided: ```tsx // this no longer works! you will end up with double elements Home // use this instead Home // this will still work as before Home ``` #### The full list of breaking changes - The minimum supported TypeScript version is 4.1 now. This was done mostly to avoid duplicated type definition files for versions that don't support automatic parameter inference from a path string, e.g. `useRoute("/:category/:page/*")` will automatically infer the type of route parameters. - Named wildcard segments are no longer supported. Instead of `/:wild*` use `/*` or `*`. The name of this parameter is always [`"*"`](https://togithub.com/lukeed/regexparam) - Use optional wildcards to define a wildcard segment with optional trailing slash, e.g. `/app/*?` will match `/app`, `/app/` and `/app/foo/bar` - Plus sign modifiers `/:user+` are no longer supported - `"wouter/static-location"` has been removed, use `memoryLocation` instead (see above) - `"wouter/use-location"` module has been renamed to `"wouter/use-browser-location"` (see above) - `Router` no longer accepts `matcher` prop. Use [`parser` props instead](https://togithub.com/molefrog/wouter/pull/337). Module '"wouter/matcher"\` has been removed. - `Route` component can no longer use scope-bypassing absolute paths, e.g. `` will no longer work. - `Router` will now always inherit base path, parser and other options from the parent router, hence `parent` prop [has been removed](https://togithub.com/molefrog/wouter/pull/343). Except for the `hook` prop, which will case all other options to reset. This is done to achieve better isolation between nested apps that use different location subscriptions (e.g. hash-based router should not inherit base from the outer location-based router). - `events` export [has been removed](https://togithub.com/molefrog/wouter/pull/348) from `"wouter/use-location"` (this module is now called `"wouter/use-browser-location"`) - Default exports have been removed from all modules - [Absolute and relative path](https://togithub.com/molefrog/wouter/pull/362) pre-processing is now part of wouter core. If you're writing a custom location hook, you no longer need to worry about handling base paths.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• [ ] If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: c6b274e8be574e0e6edc8ab4dce772961d09e1fa

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR