e2e/e2e-utils/src/devServerWarmup.ts (1)

31-35: Use a type-only import for the Page type.

ESLint flags the inline import() type annotation. Extract the type import at the top of the file for consistency with @typescript-eslint/consistent-type-imports.

♻️ Proposed fix

Add at the top of the file:

import type { Page } from '@playwright/test'

Then update the function signature:

 export async function preOptimizeDevServer(opts: {
   baseURL: string
   readyTestId?: string
-  warmup?: (page: import('@playwright/test').Page) => Promise<void>
+  warmup?: (page: Page) => Promise<void>
 }) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@e2e/e2e-utils/src/devServerWarmup.ts` around lines 31 - 35, The inline import
type in the preOptimizeDevServer parameter should be replaced with a top-level
type-only import to satisfy consistent-type-imports; add a top-level `import
type { Page } from '@playwright/test'` and change the function signature's
warmup parameter to use `Page` (i.e., warmup?: (page: Page) => Promise<void>),
updating references in preOptimizeDevServer accordingly.

packages/router-plugin/src/core/code-splitter/compilers.ts (1)

858-869: Pass an immutable splitNodeMeta into compiler plugins.

splitNodeMeta is read straight from the module-level SPLIT_NODES_CONFIG map and then handed to plugins. An accidental mutation in a plugin would leak into later properties and later files because that object instance is shared. Passing a shallow clone here would make the new extension point safer.

♻️ Possible hardening

-                          const pluginPropValue = plugin.onSplitRouteProperty?.(
-                            {
-                              programPath,
-                              callExpressionPath: path,
-                              insertionPath,
-                              routeOptions,
-                              prop,
-                              splitNodeMeta,
-                              lazyRouteComponentIdent:
-                                LAZY_ROUTE_COMPONENT_IDENT,
-                            },
-                          )
+                          const pluginPropValue = plugin.onSplitRouteProperty?.(
+                            {
+                              programPath,
+                              callExpressionPath: path,
+                              insertionPath,
+                              routeOptions,
+                              prop,
+                              splitNodeMeta: { ...splitNodeMeta },
+                              lazyRouteComponentIdent:
+                                LAZY_ROUTE_COMPONENT_IDENT,
+                            },
+                          )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/router-plugin/src/core/code-splitter/compilers.ts` around lines 858
- 869, The code passes the raw splitNodeMeta (sourced from the module-level
SPLIT_NODES_CONFIG) into compiler plugins, risking accidental mutation across
files; instead, create and pass a shallow clone (e.g., via Object.assign({},
splitNodeMeta) or {...splitNodeMeta}) when calling each plugin in the loop that
invokes opts.compilerPlugins and their onSplitRouteProperty callback so plugins
receive an immutable copy; ensure the change is applied where splitNodeMeta is
supplied to onSplitRouteProperty in compilers.ts so the original
SPLIT_NODES_CONFIG entry is not mutated.

e2e/react-start/hmr/tests/app.spec.ts (1)

13-20: Make the HMR file edit fail when the token is ambiguous.

source.replace(from, to) only rewrites the first match. If baseline or updated appears elsewhere in the route file later, this test can silently mutate the wrong spot and send you chasing a fake HMR failure.

🛠️ Proposed hardening

 async function replaceRouteText(from: string, to: string) {
   const source = await readFile(routeFile, 'utf8')
+  const firstIndex = source.indexOf(from)
+  const lastIndex = source.lastIndexOf(from)
 
-  if (!source.includes(from)) {
+  if (firstIndex === -1) {
     throw new Error(`Expected route file to include ${JSON.stringify(from)}`)
   }
+  if (firstIndex !== lastIndex) {
+    throw new Error(`Expected a single match for ${JSON.stringify(from)}`)
+  }
 
   await writeFile(routeFile, source.replace(from, to))
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@e2e/react-start/hmr/tests/app.spec.ts` around lines 13 - 20, In
replaceRouteText, the current source.replace(from, to) only changes the first
occurrence and can silently edit the wrong spot; instead read the routeFile
source, count occurrences of the from token and if count === 0 throw the
existing error, if count > 1 throw a new error indicating the token is
ambiguous, and only when count === 1 perform the replacement and writeFile;
reference replaceRouteText, routeFile, and the from/to parameters when making
this change.

packages/router-plugin/tests/add-hmr/snapshots/react/[email protected] (1)

23-53: Keep the emitted HMR helper typed under strict TS.

oldRoute, newRoute, route, and node are implicit anys here. If this snapshot is meant to reflect the generated *.tsx output, deriving these from typeof Route / typeof router.processedTree.segmentTree would keep the HMR path type-safe.
As per coding guidelines, **/*.{ts,tsx}: Use TypeScript strict mode with extensive type safety.

🔎 One low-friction way to keep the types

-      (function handleRouteUpdate(oldRoute, newRoute) {
+      (function handleRouteUpdate(
+        oldRoute: typeof Route,
+        newRoute: typeof Route,
+      ) {
@@
-        function walkReplaceSegmentTree(route, node) {
+        function walkReplaceSegmentTree(
+          route: typeof Route,
+          node: typeof router.processedTree.segmentTree,
+        ) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/router-plugin/tests/add-hmr/snapshots/react/multi-component`@true.tsx
around lines 23 - 53, The helper emits untyped parameters (oldRoute, newRoute,
route, node) causing implicit any under strict TS; annotate handleRouteUpdate
and its inner walkReplaceSegmentTree with explicit types derived from your
runtime shapes (e.g., use the Route type for oldRoute/newRoute/route and the
SegmentTree node type for node — you can import or declare a RouteLike and
SegmentNodeLike interface matching router.processedTree.segmentTree), and add
those types to the function signatures (handleRouteUpdate(oldRoute: RouteLike,
newRoute: RouteLike) and walkReplaceSegmentTree(route: RouteLike, node:
SegmentNodeLike) and any variables like filter as needed) so the snapshot emits
strictly-typed TS code.

e2e/e2e-utils/src/devServerWarmup.ts (1)

1-1: Use type-only import for Page and fix alphabetical order.

ESLint reports that Page is only used as a type annotation (in the opts parameter on line 34). Split it into a separate type import to satisfy @typescript-eslint/consistent-type-imports and fix the alphabetical ordering.

♻️ Proposed fix

-import { chromium, Page } from '@playwright/test'
+import { chromium } from '@playwright/test'
+import type { Page } from '@playwright/test'

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@e2e/e2e-utils/src/devServerWarmup.ts` at line 1, Split the combined import so
that Page is imported as a type-only import and ensure the named imports are in
alphabetical order: replace the single line "import { chromium, Page } from
'@playwright/test'" with two imports—one value import for chromium and one type
import for Page—so the type-only import satisfies
`@typescript-eslint/consistent-type-imports` and the named imports are
alphabetized; update references to Page used in the opts parameter (function
with parameter named opts) accordingly.