nextjs - 💡(How to fix) Fix packages/next-routing: `has.value` matching falls back to an unanchored regex

Summary

packages/next-routing currently matches has.value more broadly than the existing Next.js resolver.

In packages/next-routing/src/matchers.ts, matchesCondition() first tries an anchored regex and then falls back to new RegExp(conditionValue) unanchored. That means a rule like value: 'admin' matches not-admin.

The existing resolver only uses anchored matching, so this changes route behavior in a way that can affect production rewrites and middleware matching.

Repro

Route:

{
  sourceRegex: '^/dashboard$',
  destination: '/admin',
  has: [{ type: 'header', key: 'x-role', value: 'admin' }],
}

Request:

/dashboard
x-role: not-admin

Actual result in @next/routing:

• route matches
• request resolves to /admin

This comes from logic equivalent to:

const exactRegex = new RegExp(`^(?:${conditionValue})$`)
const fallbackRegex = new RegExp(conditionValue)
const match = actualValue.match(exactRegex) ?? actualValue.match(fallbackRegex)

Expected

This should not match.

Existing Next.js behavior anchors has.value matching, so admin does not match not-admin.

Why this matters

@next/routing is meant to preserve Next.js route resolution behavior for adapters. The unanchored fallback changes matcher semantics and can make has conditions broader than the equivalent Next.js config.

Suggested fix

Remove the unanchored fallback and keep anchored matching only.

If substring matching is desired at some point, it probably needs to be an explicit feature rather than a fallback behavior change.