Do experimental.paramParsers affect route matching? /c still matches [context=context].vue

[0rjan]

vue-router: 4.6.4
unplugin-vue-router: 0.19.2
experimental.paramParsers: true

I created a custom param parser at src/params/context.ts:

export const allowedContexts = ['a', 'b'] as const
export type Context = (typeof allowedContexts)[number]

export function isContext(value: unknown): value is Context {
  return !!allowedContexts.find((allowedContext) => allowedContext === value)
}

export const parser = {
  get(value: unknown): Context {
    if (isContext(value)) {
      return value
    }
    throw new Error(
      `Invalid context: "${value}". Expected one of: ${allowedContexts.join(', ')}`
    )
  },

  set(value: unknown): Context {
    if (isContext(value)) {
      return value
    }
    throw new Error(
      `Invalid context: "${value}". Expected one of: ${allowedContexts.join(', ')}`
    )
  },
}

My page file is:
src/pages/[context=context].vue

This gives me correct typing (route.params.context is typed as "a" | "b").
However when I navigate to /c:

• the router resolves to src/pages/[context=context].vue
• route.params.context is "c"
• I expected the param parser to prevent invalid values from being accepted, but I’m not seeing that behavior.

Questions

1. Can definePage({ params: ... }) be used to select/declare which param parser to use? Autocomplete shows definePage has a params property, but I couldn’t get it to connect to my parser. Is filename syntax ([context=context]) the only supported way?
2. Are param parsers intended to affect route matching?
3. If parsers don’t restrict matching, what’s the recommended way to enforce allowed param values without duplication/drift? This works:

definePage({ path: '/:context(a|b)' })

...but now allowed values exist in two places (parser file + path in definePage).

Goal

• typed params ("a" | "b")
• runtime enforcement so /c doesn’t resolve to the context page
• ideally a single source of truth for allowed values

What’s the intended pattern here? Thanks for any clarification!

[PindaPixel]

The examples that can be found on param parser miss() instead of just a regular error, could that be the difference? https://github.com/vuejs/router/blob/main/packages/router/src/experimental/route-resolver/matchers/errors.ts

[posva]

What did you expect? What is failing?

[0rjan]

With a param parser defined via the filename ([context=context].vue), I would expect it to affect runtime matching as well, not just generate types.

If context only allows "a" | "b", then navigating to /c (initial load or direct URL access) would ideally not match that route and instead fall through to the catch-all. That is what happens when using a custom regex in params, for example definePage({ name: 'Context', path: '/:context(a|b)' }).

There are two aspects:

1. URL-based navigation
   When using a param parser, /c would ideally not match and fall through, similar to the custom regex in params case.

2. Programmatic navigation
   Programmatic navigation like

   router.push({ name: 'Context', params: { context: 'c' } })

   would ideally also not succeed when the param is invalid. Currently it is possible to programmatically navigate to an invalid route even when using a custom regex in params.

[posva]

Your expectation is correct so a reproduction should help. Maybe you’re not using the experimental_createRouter. That part is still not documented and it’s required for param parsers. Also make sure to use the latest Vue router

[0rjan]

I will try soon. Thanks!
Keep you posted.

[posva]

FYI In latest release (Vue router) miss() already throws