packages/router/src/experimental/route-resolver/resolver-dynamic.ts (3)

1-8: Resolved: relative imports are consistent with codebase conventions

Switching to relative imports here aligns with the repository’s dependency hierarchy and avoids circular deps per the learnings. Looks good.

Also applies to: 20-21

---

113-116: Resolved: use of warn() instead of console.warn

Using the imported warn() maintains consistency with the rest of the codebase.

---

269-276: removeMatcher() leaves stale entries and parent references

Currently only matcherMap is updated. Stale entries remain in matchers; parent.children keeps references; aliases aren’t cleaned. This causes future resolutions to still hit removed routes.

Apply this diff to fully remove a matcher, its aliases, and detach it from its parent:

   function removeMatcher(matcher: TMatcherRecord) {
     matcherMap.delete(matcher.name)
-    for (const child of matcher.children) {
+    // remove children first
+    for (const child of [...matcher.children]) {
       removeMatcher(child)
     }
-    // TODO: delete from matchers
-    // TODO: delete children and aliases
+    // detach from parent.children
+    if (matcher.parent) {
+      const idx = matcher.parent.children.indexOf(matcher)
+      if (idx > -1) matcher.parent.children.splice(idx, 1)
+    }
+    // remove this matcher and any aliases pointing to it
+    for (let i = matchers.length - 1; i >= 0; i--) {
+      const m = matchers[i]
+      if (m === matcher || m.aliasOf === matcher) {
+        matchers.splice(i, 1)
+      }
+    }
+    // clear own children to avoid stale references
+    matcher.children = []
   }

packages/router/vitest.config.ts (3)

28-30: Remove redundant exclusion; keep only the glob.

'src/experimental/**/*.ts' already matches 'src/experimental/index.ts'. Dropping the specific entry avoids duplication and keeps the list lean.

-        'src/experimental/index.ts',

---

29-29: Use an actionable TODO with ownership and intent.

Replace the generic FIXME with a TODO that states when to remove the exclusion and who owns the follow-up.

-        // FIXME: add more tests
+        // TODO(router): add tests for experimental resolver and remove this exclusion before stabilizing

---

30-30: Consider tracking experimental coverage separately instead of blanket exclusion.

Excluding the entire experimental tree hides coverage signal for the new resolver while it evolves. A separate Vitest config (or project) dedicated to experimental code can keep main coverage stable without losing visibility.

Example: add a dedicated config to run in CI as a non-blocking job.

// packages/router/vitest.experimental.config.ts
import { defineConfig } from 'vitest/config'
import Vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [Vue()],
  test: {
    coverage: {
      include: ['src/experimental/**/*.ts'],
      exclude: [
        'src/**/*.d.ts',
        'src/**/*.test-d.ts',
        'src/**/*.spec.ts',
      ],
      // optional: separate report dir to avoid clobbering main
      // reportsDirectory: './coverage-experimental',
    },
    typecheck: {
      enabled: true,
      checker: 'vue-tsc',
    },
  },
})

Then wire a script like vitest --config vitest.experimental.config.ts --run in CI for visibility without affecting the main coverage gate.

packages/router/src/experimental/route-resolver/resolver-dynamic.ts (4)

283-286: Return a copy from getRecords() to prevent external mutation

Expose a defensive copy to avoid accidental external mutations of the internal ordering.

   function getRecords() {
-    return matchers
+    return matchers.slice()
   }

---

55-57: Typo: “Prevoisly” → “Previously”

-   * Remove all matcher records. Prevoisly named `clearRoutes()`.
+   * Remove all matcher records. Previously named `clearRoutes()`.

---

134-137: Typo: “catched” → “caught”

-      // either one of them must be defined and is catched by the dev only warn above
+      // either one of them must be defined and is caught by the dev-only warn above

---

375-379: Remove stray debug/TODO comment noise

These comments appear to be leftover scratch notes and add noise.

-} // pathEncoded`/users/${1}`
-// TODO:
-// pathEncoded`/users/${null}/end`
-// const a: RouteRecordRaw = {} as any
+}

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these settings in your CodeRabbit configuration.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/index.ts:43-44
Timestamp: 2025-08-11T15:22:32.526Z
Learning: In the Vue Router codebase, files within the src directory should not import from src/index to avoid circular dependencies. Deep imports like `../matcher/types` are intentional and necessary for maintaining proper dependency hierarchy.

packages/router/src/experimental/router.ts (5)

281-281: Fix typo in interface name: EXPERIMENTAL_RouteRecordNoramlized_Base → EXPERIMENTAL_RouteRecordNormalized_Base

The interface name is misspelled. This typo should be fixed to avoid confusion and maintain consistency.

Apply this diff to fix the typo:

-export interface EXPERIMENTAL_RouteRecordNoramlized_Base {
+export interface EXPERIMENTAL_RouteRecordNormalized_Base {

---

311-311: Update extends clauses to use the corrected interface name

After fixing the typo in the base interface name, update the extends clauses in these two interfaces.

Apply this diff:

 export interface EXPERIMENTAL_RouteRecordNormalized_Group
-  extends EXPERIMENTAL_RouteRecordNoramlized_Base,
+  extends EXPERIMENTAL_RouteRecordNormalized_Base,
     EXPERIMENTAL_RouteRecord_Group {
   meta: RouteMeta
   parent: EXPERIMENTAL_RouteRecordNormalized | null
 }

 // TODO: is it worth to have 2 types for the undefined values?
 export interface EXPERIMENTAL_RouteRecordNormalized_Matchable
-  extends EXPERIMENTAL_RouteRecordNoramlized_Base,
+  extends EXPERIMENTAL_RouteRecordNormalized_Base,
     EXPERIMENTAL_RouteRecord_Matchable {
   meta: RouteMeta

Also applies to: 319-319

---

675-703: Address TypeScript compatibility issues in resolve function

Multiple type compatibility issues are suppressed with @ts-expect-error comments. These should be properly resolved with type mappings or adapters.

Consider creating proper type mappings between the experimental resolver types and existing router types to eliminate these suppressions. The type mismatches on lines 676-677, 679, and 697-698 indicate a fundamental incompatibility between the resolver's expected types and what's being passed.

---

870-884: Critical: Using wrong variable in redirect logic

In the NAVIGATION_GUARD_REDIRECT branch, the code uses shouldRedirect (from line 787) instead of failure.to when resolving the redirect location. This will cause incorrect redirects.

Apply this diff to fix the redirect logic:

           return pushWithRedirect(
             {
-              // @ts-expect-error: FIXME: refactor location types
-              ...resolve(shouldRedirect, currentRoute.value),
+              // target the guard-provided redirect
+              ...resolve(failure.to, currentRoute.value),
               state:
                 typeof failure.to === 'object'
                   ? assign({}, data, failure.to.state)
                   : data,
               force,
             },

---

1367-1373: Resolve global properties typing issue

The @ts-expect-error on line 1367 indicates a type mismatch between EXPERIMENTAL_Router and the expected Router type for $router. This should be properly resolved with module augmentation.

Add proper module augmentation in packages/router/src/experimental/index.ts:

declare module 'vue' {
  export interface ComponentCustomProperties {
    $router: EXPERIMENTAL_Router
    $route: RouteLocationNormalizedLoaded
  }
}

Alternatively, use a type-safe cast:

type RouterAdapter = { $router: EXPERIMENTAL_Router } & Record<string, unknown>
;(app.config.globalProperties as unknown as RouterAdapter).$router = router

packages/router/src/experimental/route-resolver/matcher-resolve.spec.ts (5)

34-46: Consider using existing EXPERIMENTAL_RouteRecordRaw type instead of redefining it.

This interface extends NEW_MatcherRecordRaw with the same properties that are likely already defined elsewhere in the experimental router system. Since this is a test file, consider importing the actual type if it exists to maintain consistency.

---

68-112: Add explicit return type annotation to compileRouteRecord function.

The function returns NEW_MatcherRecordRaw but lacks an explicit return type annotation, which would improve type safety and code documentation.

 function compileRouteRecord(
   record: RouteRecordRaw,
   parentRecord?: RouteRecordRaw
-): NEW_MatcherRecordRaw {
+): NEW_MatcherRecordRaw {

---

74-76: Improve error message for routes without absolute paths.

The error message could be more specific about which route is causing the issue to aid debugging.

   if (!parentRecord && !record.path.startsWith('/')) {
-    throw new Error(`Record without parent must have an absolute path`)
+    throw new Error(`Record "${record.name || record.path}" without parent must have an absolute path`)
   }

---

86-86: Remove commented-out console.log statements.

Debug logging statements should be removed from test code before merging.

-  // console.log({ record, parser })

   return {
     group: !isMatchable(record),
     name: record.name,
     score: parser.score,

     path: {
       match(value) {
         const params = parser.parse(value)
-        // console.log('🌟', parser.re, value, params)
         if (params) {
           return params
         }

Also applies to: 96-96

---

429-459: Several TODO tests should be reviewed for implementation priority.

Multiple tests are marked with .todo which means they're not being executed:

• Line 429: "keep optional params from parent record"
• Line 462: "discards non existent params" (has implementation but marked as todo)
• Line 509: "warns if a path isn not absolute"

Consider prioritizing which of these tests should be implemented for the experimental resolver to be feature-complete.

Would you like help implementing any of these pending test cases?

Also applies to: 509-515

packages/router/src/experimental/route-resolver/old/resolver-dynamic.test-d.ts (1)

43-43: Fix typo in test description.

There's a typo in the test description: "resolved" should be "resolves".

-    it('resolved named locations', () => {
+    it('resolves named locations', () => {

packages/router/src/experimental/route-resolver/old/resolver-dynamic.spec.ts (2)

19-27: Consider extracting the PAGE_QUERY_PATTERN_MATCHER to test utilities.

This matcher pattern could be useful for other tests. Consider moving it to the test-utils file alongside other test matchers.

---

103-103: Complete the TODO test suite for absolute locations as strings.

The describe.todo block indicates incomplete test coverage for absolute string locations. This is an important test case that should be implemented.

Would you like me to help implement the complete test suite for absolute locations as strings? The current tests inside seem functional but the describe block is marked as todo.

packages/router/src/experimental/route-resolver/resolver-abstract.ts (2)

151-164: Consider improving error handling in decode function.

The decode function catches errors but only logs in dev mode. Consider returning the original text wrapped in a result type or throwing a more descriptive error for production to help with debugging encoding issues.

 export function decode(
   text: string | number | null | undefined
 ): string | null {
   if (text == null) return null
   try {
     return decodeURIComponent('' + text)
   } catch (err) {
-    __DEV__ && warn(`Error decoding "${text}". Using original value`)
+    if (__DEV__) {
+      warn(`Error decoding "${text}". Using original value. Error: ${err}`)
+    }
   }
   return '' + text
 }

---

189-192: Remove or properly type the commented-out encodeQueryValue overload.

The @ts-expect-error comment and the overload definition suggest incomplete implementation. Either implement it properly or remove it.

-// @ts-expect-error: overload are not correctly identified
-const encodeQueryValue: FnStableNull =
-  // for ts
-  value => (value == null ? null : _encodeQueryValue(value))
+const encodeQueryValue: FnStableNull = ((value: string | number | null | undefined) => 
+  value == null ? null : _encodeQueryValue(value)) as FnStableNull

packages/router/src/experimental/route-resolver/old/resolver-dynamic.ts (2)

375-378: Remove commented-out code at the end of the file.

These comments appear to be leftover development notes and should be removed.

-} // pathEncoded`/users/${1}`
-// TODO:
-// pathEncoded`/users/${null}/end`
-// const a: RouteRecordRaw = {} as any
+}

---

112-132: Improve error message for unnamed relative location warning.

The error message could be more actionable by suggesting what the user should do.

         warn(
-          `Cannot resolve an unnamed relative location without a current location. This will throw in production.`,
+          `Cannot resolve an unnamed relative location without a current location. Please provide either a 'name' field or a currentLocation parameter. This will throw in production.`,
           to
         )

packages/router/src/experimental/router.ts (2)

305-307: Consider removing Options API dependency

The comment indicates that the instances property is only needed for Options API navigation guards. Consider documenting a migration path or timeline for removing this dependency.

Since this is marked as "FIXME", consider:

1. Adding a deprecation notice if Options API support will be removed
2. Providing a migration guide for users relying on Options API guards
3. Making this property optional if it's truly only for Options API

---

919-921: Consider extracting app context logic

The runWithContext function retrieves the first installed app, which might not be the intended app in multi-app scenarios.

Consider:

1. Document that this uses the first installed app's context
2. Consider passing the specific app context when available
3. Add a warning in dev mode when multiple apps are installed

 function runWithContext<T>(fn: () => T): T {
   const app: App | undefined = installedApps.values().next().value
+  if (__DEV__ && installedApps.size > 1) {
+    warn('Multiple apps detected. Using context from the first installed app.')
+  }
   return app?.runWithContext ? app.runWithContext(fn) : fn()
 }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these settings in your CodeRabbit configuration.

.git-crypt/.gitattributes (1)

3-4: Optional hardening for attributes

If you keep this, consider also disabling EOL normalization in this directory to prevent any platform-specific transforms on key material:

-* !filter !diff
+* !filter !diff -text

Additionally, ensure the directory is excluded from published npm artifacts (via files field or .npmignore) to avoid shipping crypto metadata in packages.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

packages/router/src/experimental/route-resolver/old/matcher-resolve.spec.ts (8)

61-66: joinPaths produces 'undefined/' and an extra trailing slash for empty child paths.

If a is undefined, joinPaths returns strings like 'undefined/foo'. If b is an empty string (e.g., nested routes with ''), it returns '/parent/' instead of '/parent'. Safer handling avoids surprising slashes.

Apply this diff:

-export function joinPaths(a: string | undefined, b: string) {
-  if (a?.endsWith('/')) {
-    return a + b
-  }
-  return a + '/' + b
-}
+export function joinPaths(a: string | undefined, b: string) {
+  if (!a) return b
+  if (!b) return a
+  return a.endsWith('/') ? a + b : a + '/' + b
+}

---

74-85: Avoid mutating input records in compileRouteRecord.

Mutating record.path has side effects that can surprise callers and complicate future reuse. Compute an absolute path locally and pass a normalized parent down to children.

Apply this diff:

-  const path = record.path.startsWith('/')
-    ? record.path
-    : joinPaths(parentRecord?.path, record.path)
-  record.path = path
-  const parser = tokensToParser(
-    tokenizePath(record.path),
+  const absolutePath = record.path.startsWith('/')
+    ? record.path
+    : joinPaths(parentRecord?.path, record.path)
+  const parser = tokensToParser(
+    tokenizePath(absolutePath),
     mergeOptions(PATH_PARSER_OPTIONS_DEFAULTS, record)
   )
@@
-    children: record.children?.map(childRecord =>
-      compileRouteRecord(childRecord, record)
-    ),
+    children: record.children?.map(childRecord =>
+      compileRouteRecord(childRecord, { ...record, path: absolutePath })
+    ),

Also applies to: 105-108

---

53-59: Treat single-component records as matchable.

Records that only define component (singular) should also be considered matchable. Current guard only checks components and misses component.

Apply this diff:

-function isMatchable(record: RouteRecordRaw): boolean {
-  return !!(
-    record.name ||
-    (record.components && Object.keys(record.components).length) ||
-    record.redirect
-  )
-}
+function isMatchable(record: RouteRecordRaw): boolean {
+  return !!(
+    record.name ||
+    record.component ||
+    (record.components && Object.keys(record.components).length) ||
+    record.redirect
+  )
+}

---

139-143: Strengthen the type guard for experimental records.

Using typeof record.path !== 'string' is brittle. Guard against the actual MatcherPatternPath shape (presence of match and build).

Apply this diff:

-  return typeof record.path !== 'string'
+  return (
+    record != null &&
+    typeof record.path === 'object' &&
+    record.path !== null &&
+    'match' in record.path &&
+    'build' in record.path
+  )

---

196-203: Only hide matched from assertions when it’s not part of expectations.

Right now, matched is always set to a non-enumerable empty array, which prevents asserting it even when provided in expectedLocation. Keep the current behavior by default, but allow assertions when the test provides matched.

Apply this diff:

-    Object.defineProperty(resolved, 'matched', {
-      writable: true,
-      configurable: true,
-      enumerable: false,
-      // FIXME: build it
-      value: [],
-    })
+    if (!('matched' in expectedLocation)) {
+      Object.defineProperty(resolved, 'matched', {
+        writable: true,
+        configurable: true,
+        enumerable: false,
+        // FIXME: build it
+        value: [],
+      })
+    }

---

81-85: Limit parser options passed to tokensToParser for clarity.

Passing the entire record relies on mergeOptions ignoring unrelated keys. Being explicit improves readability and type-safety.

You can refactor this portion:

-  const parser = tokensToParser(
-    tokenizePath(absolutePath),
-    mergeOptions(PATH_PARSER_OPTIONS_DEFAULTS, record)
-  )
+  const parser = tokensToParser(
+    tokenizePath(absolutePath),
+    mergeOptions(PATH_PARSER_OPTIONS_DEFAULTS, {
+      strict: (record as any).strict,
+      end: (record as any).end,
+      sensitive: (record as any).sensitive,
+    })
+  )

If RouteRecordRaw already includes these fields, drop the casts and rely on types.

---

501-507: Typo in test description.

Fix “isn not” → “is not”.

Apply this diff:

-    it.todo('warns if a path isn not absolute', () => {
+    it.todo('warns if a path is not absolute', () => {

---

371-497: Add query/hash resolution tests to align with the PR objective.

Given the resolver now supports matching based on query (and custom parsing/serialization), consider adding cases that:

• Resolve by name/path with query filters that match and that don’t match.
• Verify query serialization consistency in fullPath.
• Include hash handling.

I can draft these tests to match the new resolver behavior if helpful.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

packages/router/package.json (1)

8-8: Ship CJS typings too (.d.cts) or confirm resolution strategy

You’ve switched to ESM declarations via .d.mts at the package level. Ensure CommonJS consumers also get correct typings (typically by shipping a .d.cts alongside). Otherwise, CJS projects and TS NodeNext users may see resolution quirks.

packages/router/package.json (3)

30-30: Add types for the experimental export

Subpath "./experimental" points to an ESM file but lacks a types mapping. Add an explicit types path to improve TS resolution and editor UX.

Apply this diff:

-    "./experimental": "./dist/experimental/index.mjs",
+    "./experimental": {
+      "types": "./dist/experimental/index.d.mts",
+      "import": "./dist/experimental/index.mjs"
+    },

If the declaration file isn’t emitted yet, we can adjust the build to output dist/experimental/index.d.mts.

---

86-87: Include .d.cts in the published files if you generate CJS declarations

If you decide to ship CommonJS declaration files, make sure they’re published too.

Apply this diff:

-    "dist/**/*.d.{ts,mts}",
+    "dist/**/*.d.{ts,mts,cts}",

---

95-98: Make build:dts idempotent to avoid duplicate appends

Current tail >> dist/vue-router.d.mts will append on every run, creating duplicate global extensions in repeated builds/tests.

Apply this diff to delegate to a small script that checks before appending:

-    "build:dts": "tail -n +10 src/globalExtensions.ts >> dist/vue-router.d.mts",
+    "build:dts": "node scripts/append-global-extensions.mjs",

And add scripts/append-global-extensions.mjs:

// scripts/append-global-extensions.mjs
import { readFileSync, writeFileSync, existsSync } from 'node:fs';

const out = 'dist/vue-router.d.mts';
const marker = '// @vue-router:globalExtensions-appended';
const src = 'src/globalExtensions.ts';

// Ensure base declaration exists (built by `pnpm run build`)
if (!existsSync(out)) {
  throw new Error(`Missing ${out}. Run "pnpm run build" before build:dts.`);
}

const content = readFileSync(out, 'utf8');
if (content.includes(marker)) {
  // already appended, nothing to do
  process.exit(0);
}

// drop first 9 lines to keep parity with previous tail -n +10
const srcContent = readFileSync(src, 'utf8').split('\n').slice(9).join('\n');

writeFileSync(
  out,
  `${content}\n\n${marker}\n${srcContent}\n`,
  'utf8'
);
console.log('Appended globalExtensions to vue-router.d.mts');

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/index.ts:43-44
Timestamp: 2025-08-11T15:22:32.526Z
Learning: In the Vue Router codebase, files within the src directory should not import from src/index to avoid circular dependencies. Deep imports like `../matcher/types` are intentional and necessary for maintaining proper dependency hierarchy.

packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts (3)

440-454: Remove or implement the commented-out build()

The method is still commented. Either drop it or implement it (with proper set + encodeParam usage and required-param handling) to avoid dead code in the experimental surface.

I can help implement it consistent with the ParamParser contract and the current opts semantics if you want to go that route.

---

159-165: Avoid emitting literal "null"/"undefined" in URLs when using default set

PATH_PARAM_DEFAULT_SET converts nullish values to the strings "null"/"undefined". This conflicts with encodeParam’s nullish handling (which intentionally yields an empty segment). Return null for nullish input so downstream encoding works as intended.

Apply this diff:

-const PATH_PARAM_DEFAULT_SET = (value: string | string[] | null | undefined) =>
-  value && Array.isArray(value) ? value.map(String) : String(value)
+const PATH_PARAM_DEFAULT_SET = (value: string | string[] | null | undefined) =>
+  value == null
+    ? null
+    : Array.isArray(value)
+      ? value.map(String)
+      : String(value)

---

105-121: Preserve original casing in star prefix; keep a separate lowercase cache for matching

MatcherPatternPathStar lowercases and stores the prefix in this.path, so build() emits a lower-cased prefix (e.g., /MyTeam → /myteam). Mirror the static matcher pattern: keep the original prefix for building and a lowercased cache for matching.

Apply this diff:

-  private path: string
-  constructor(path: string = '') {
-    this.path = path.toLowerCase()
-  }
+  private path: string
+  private pathi: string
+  constructor(path: string = '') {
+    this.path = path
+    this.pathi = path.toLowerCase()
+  }
@@
-  match(path: string): { pathMatch: string } {
-    if (!path.toLowerCase().startsWith(this.path)) {
+  match(path: string): { pathMatch: string } {
+    if (!path.toLowerCase().startsWith(this.pathi)) {

packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts (3)

323-330: Fix dev warning to report accurate counts (capture groups vs defined params)

The current message uses match.length (includes the full match) and prints i but checks object key lengths. Compute group count as match.length - 1 and compare against this.paramsKeys.length.

Apply this diff:

-    if (
-      __DEV__ &&
-      Object.keys(params).length !== Object.keys(this.params).length
-    ) {
-      warn(
-        `Regexp matched ${match.length} params, but ${i} params are defined. Found when matching "${path}" against ${String(this.re)}`
-      )
-    }
+    if (__DEV__) {
+      const matchedCount = match.length - 1
+      const definedCount = this.paramsKeys.length
+      if (matchedCount !== definedCount) {
+        warn(
+          `Regexp matched ${matchedCount} params, but ${definedCount} params are defined. Found when matching "${path}" against ${String(this.re)}`
+        )
+      }
+    }

---

89-101: Typo: “folllowed” → “followed”

Minor doc fix.

Apply this diff:

- * Allows matching a static path folllowed by anything.
+ * Allows matching a static path followed by anything.

---

405-413: Typo in docs: “patch” → “path”

Minor doc fix.

Apply this diff:

-   * @throws if the patch doesn't match
+   * @throws if the path doesn't match

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:0-0
Timestamp: 2025-08-14T13:58:50.446Z
Learning: The `encodeParam` function in vue-router handles nullish values (null/undefined) by returning an empty string, rather than stringifying them to "null" or "undefined". This means missing parameters in route building result in empty path segments rather than literal "undefined" in URLs.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:0-0
Timestamp: 2025-08-14T13:58:50.446Z
Learning: The `encodeParam` function in vue-router has the signature `(text: string | number | null | undefined): string` and specifically handles nullish values by returning an empty string via `text == null ? '' : encodePath(text).replace(SLASH_RE, '%2F')`. This means missing or null parameters in route building result in empty path segments rather than literal "null"/"undefined" strings in URLs.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:127-129
Timestamp: 2025-08-14T13:59:53.367Z
Learning: NoInfer<T> is a native TypeScript utility type introduced in TypeScript 5.4 (March 2024) that prevents type inference in generic contexts. It does not need to be defined or imported in TypeScript projects using version 5.4 or later.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:127-129
Timestamp: 2025-08-14T13:59:53.367Z
Learning: NoInfer<T> is a native TypeScript utility type introduced in TypeScript 5.4 that prevents type inference in generic contexts. It does not need to be defined or imported in TypeScript projects using version 5.4 or later.

packages/router/src/experimental/index.ts (1)

45-45: Fix typo in comment.

“realying” → “relying”.

-// this should create type errors if someone is realying on children
+// this should create type errors if someone is relying on children

packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts (1)

73-86: Preserves original casing while matching case-insensitively — good fix

Storing the original path and a lowercased copy (pathi) ensures match() is case-insensitive while build() returns the original casing. This addresses prior casing concerns without mutating consumer input.

packages/router/src/experimental/route-resolver/matchers/param-parsers/types.ts (1)

20-22: Clarify optional/null handling in ParamParser_Generic.

ParamParser_Generic covers single vs repeatable inputs but excludes null. If the intent is “non-optional path params only”, consider clarifying the JSDoc; otherwise, include the optional case.

Apply one of:

- * Generic type for a param parser that can handle both single and repeatable params.
+ * Generic type for a param parser that can handle both single and repeatable (non-optional) params.

Or expand the type:

 export type ParamParser_Generic =
-  | ParamParser<any, string>
-  | ParamParser<any, string[]>
+  | ParamParser<any, string>
+  | ParamParser<any, string[]>
+  | ParamParser<any, string | null>
+  | ParamParser<any, string[] | null>

packages/router/src/experimental/route-resolver/matchers/matcher-pattern-path-star.ts (3)

5-5: Fix typo in JSDoc.

“folllowed” → “followed”.

- * Allows matching a static path folllowed by anything.
+ * Allows matching a static path followed by anything.

---

22-24: Preserve original path casing when building; keep lowercase only for matching.

Lowercasing this.path and reusing it in build() changes the user-supplied prefix casing (e.g. '/Team' becomes '/team'). Keep a lowercase copy for comparisons and the original for output.

 export class MatcherPatternPathStar
   implements MatcherPatternPath<{ pathMatch: string }>
 {
-  private path: string
+  private basePath: string
+  private basePathLower: string
   constructor(path: string = '') {
-    this.path = path.toLowerCase()
+    this.basePath = path
+    this.basePathLower = path.toLowerCase()
   }

   match(path: string): { pathMatch: string } {
-    if (!path.toLowerCase().startsWith(this.path)) {
+    if (!path.toLowerCase().startsWith(this.basePathLower)) {
       throw miss()
     }
     return {
-      pathMatch: path.slice(this.path.length),
+      pathMatch: path.slice(this.basePathLower.length),
     }
   }

   build(params: { pathMatch: string }): string {
-    return this.path + params.pathMatch
+    return this.basePath + params.pathMatch
   }
 }

Also applies to: 35-37

---

4-17: Document the case-insensitive nature of matching.

The implementation lowercases both sides; call this out to avoid surprises.

 /**
- * Allows matching a static path followed by anything.
+ * Allows matching a static path followed by anything (case-insensitive).
+ * Matching lowercases both the base path and the input path, but `build()` preserves
+ * the original casing of the base path.

packages/router/src/experimental/route-resolver/matchers/param-parsers/index.ts (2)

12-17: Consider allowing optional inputs in defineParamParser.

Today TIn excludes null, while ParamParser defaults include it. If you want to author parsers for optional params via this helper, allow null too.

-export function defineParamParser<TOut, TIn extends string | string[]>(parser: {
+export function defineParamParser<TOut, TIn extends string | string[] | null>(parser: {
   get?: (value: TIn) => TOut
   set?: (value: TOut) => TIn
 }): ParamParser<TOut, TIn> {
   return parser
 }

---

31-31: Type-only re-export to avoid value export noise.

Re-export ParamParser as a type-only export.

-export { ParamParser }
+export type { ParamParser }

packages/router/src/experimental/route-resolver/matchers/param-parsers/numbers.ts (3)

2-2: Use type-only import for ParamParser.

Avoids emitting an unnecessary runtime import.

-import { ParamParser } from './types'
+import type { ParamParser } from './types'

---

32-39: Place JSDoc immediately before the intended declaration.

The doc block appears after the previous const; move it above PARAM_PARSER_INT to ensure TypeDoc picks it up correctly.

-} satisfies ParamParser<number[] | null, string[] | null> /**
- * Native Param parser for integers.
- *
- * @internal
- */
-
-export const PARAM_PARSER_INT: ParamParser<number | number[] | null> = {
+} satisfies ParamParser<number[] | null, string[] | null>
+
+/**
+ * Native Param parser for integers.
+ *
+ * @internal
+ */
+export const PARAM_PARSER_INT: ParamParser<number | number[] | null> = {

---

6-11: Minor: redundant finiteness check after integer regex.

Given IS_INTEGER_RE already restricts to integers, Number(value) will always be finite. The extra Number.isFinite(num) is harmless but unnecessary.

No change required; feel free to keep for explicitness.

packages/router/src/experimental/index.ts (1)

42-42: Type-only re-export for MatchMiss.

If MatchMiss is a type, re-export it as type-only to avoid value export churn.

-export { miss, MatchMiss } from './route-resolver/matchers/errors'
+export { miss } from './route-resolver/matchers/errors'
+export type { MatchMiss } from './route-resolver/matchers/errors'

Confirm MatchMiss is a type (or interface). If it’s a value, keep the current value export.

packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts (3)

164-171: Fix DEV warning: wrong condition and off-by-one in captured params count

The current check compares object key counts (which are always equal here) and reports match.length (includes the full match). This warning will never trigger and misreports counts.

Proposed fix:

• Compare the number of capturing groups (match.length - 1) with the number of defined params (this.paramsKeys.length).
• Update the message accordingly.

-    if (
-      __DEV__ &&
-      Object.keys(params).length !== Object.keys(this.params).length
-    ) {
-      warn(
-        `Regexp matched ${match.length} params, but ${i} params are defined. Found when matching "${path}" against ${String(this.re)}`
-      )
-    }
+    if (__DEV__) {
+      const captured = match.length - 1
+      const defined = this.paramsKeys.length
+      if (captured !== defined) {
+        warn(
+          `Regexp matched ${captured} params, but ${defined} params are defined. Found when matching "${path}" against ${String(this.re)}`
+        )
+      }
+    }

---

187-189: Tighten the inferred return type to the specific setter instance

Using ReturnType<NonNullable<ParamParser['set']>> loses the concrete generic instantiation for each param. Basing the return type on the actual paramOptions.set preserves the precise TIn/TOut pair and improves type safety.

-            const value: ReturnType<NonNullable<ParamParser['set']>> = (
+            const value: ReturnType<NonNullable<typeof paramOptions['set']>> = (
               paramOptions.set || identityFn
             )(params[paramName])

-                const value: ReturnType<NonNullable<ParamParser['set']>> = (
+                const value: ReturnType<NonNullable<typeof paramOptions['set']>> = (
                   paramOptions.set || identityFn
                 )(params[paramName])

Also applies to: 203-205

---

176-190: I wasn’t able to confirm how pathParts is constructed (i.e. that its numeric entries truly represent indexes into this.paramsKeys), so I can’t guarantee the safety of dropping paramIndex. Please review the builder(s) of this class to ensure the numbers in pathParts are always aligned with Object.keys(this.params). If they are, the suggested diff is sound; otherwise, retaining the positional counter avoids introducing subtle mismatches.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:0-0
Timestamp: 2025-08-14T13:58:50.446Z
Learning: The `encodeParam` function in vue-router handles nullish values (null/undefined) by returning an empty string, rather than stringifying them to "null" or "undefined". This means missing parameters in route building result in empty path segments rather than literal "undefined" in URLs.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:0-0
Timestamp: 2025-08-14T13:58:50.446Z
Learning: The `encodeParam` function in vue-router has the signature `(text: string | number | null | undefined): string` and specifically handles nullish values by returning an empty string via `text == null ? '' : encodePath(text).replace(SLASH_RE, '%2F')`. This means missing or null parameters in route building result in empty path segments rather than literal "null"/"undefined" strings in URLs.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:127-129
Timestamp: 2025-08-14T13:59:53.367Z
Learning: NoInfer<T> is a native TypeScript utility type introduced in TypeScript 5.4 (March 2024) that prevents type inference in generic contexts. It does not need to be defined or imported in TypeScript projects using version 5.4 or later.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/route-resolver/matchers/matcher-pattern.ts:127-129
Timestamp: 2025-08-14T13:59:53.367Z
Learning: NoInfer<T> is a native TypeScript utility type introduced in TypeScript 5.4 that prevents type inference in generic contexts. It does not need to be defined or imported in TypeScript projects using version 5.4 or later.

Learnt from: posva
PR: vuejs/router#2415
File: packages/router/src/experimental/index.ts:43-44
Timestamp: 2025-08-11T15:22:32.526Z
Learning: In the Vue Router codebase, files within the src directory should not import from src/index to avoid circular dependencies. Deep imports like `../matcher/types` are intentional and necessary for maintaining proper dependency hierarchy.