[yangshun]

Allow typed route destination objects in router.visit(), router.prefetch(), router.flush(), and c.rewrite(). Known route patterns autocomplete and dynamic routes require matching path parameters, while existing string and supported URL inputs continue to work.

router.visit({
  pathname: '/users/:id',
  params: { id: 42 },
  query: { tab: 'activity' },
  hash: 'details',
});

Export RouteDestination and RouteUrlInput from void/routes and serialize destinations through the same builder as routeUrl(). c.redirect() retains Hono's string/URL signature; typed redirects use c.redirect(routeUrl(...)).

Coverage includes generated and package declarations, redirect/rewrite behavior, and client navigation/cache behavior across the four adapters.

Validation with the dependent Link commit applied:

• vp run check: 33/33 tasks passed.
• vp test run: 15,379 passed, 31 skipped.
• Scoped formatting and lint passed.

[cpojer]

In hindsight, I feel like we should have shipped with typed routes from the start.

I'm not actually sure I love this implementation of passing objects around – it's probably fine because AI writes it, but since Void manages the route map, I'm wondering if we could type these as "Route" which is a set of strings like type Route = '/login' | '/feed' | \/profile?user=${string}`;` – but probably too late to add this to Void.

[yangshun]

In hindsight, I feel like we should have shipped with typed routes from the start.

Possibly, but never too late! FWIW Next.js took more than 5 years to add typed routes.

I'm not actually sure I love this implementation of passing objects around – it's probably fine because AI writes it, but since Void manages the route map, I'm wondering if we could type these as "Route" which is a set of strings like type Route = '/login' | '/feed' | \/profile?user=${string}; – but probably too late to add this to Void.

I understand. Personally I prefer the objects way. Actually we can support both objects and route union ways, we could add a flag to the Void plugin config to generate the route unions instead of strings. Next.js does this.

const nextConfig = {
  typedRoutes: true,
}

I'll leave the decision to you as to which combination to allow:

• Untyped values
• Objects
• Route unions:
  1. Opt-in (turns off untyped)
  2. Always on (I think this is considered a breaking change but no runtime difference, so might be ok?)

My recommendation would be untyped + objects + opt-in route unions.