Analysis

When using a src directory structure (src/pages or src/app), the build process should detect if middleware or instrumentation files are incorrectly placed at the project root instead of inside the src/ directory, and throw a clear error to guide users.

However, there's a bug in the file detection logic on line 1144. The code calculates:

const rootDir = path.join((pagesDir || appDir)!, '..')

When pagesDir is /project/src/pages, this results in rootDir = /project/src. The subsequent getFilesInDir(rootDir) call only searches within the src directory, completely missing files that are incorrectly placed at the actual project root (/project/).

This means users who place middleware.js or instrumentation.js at the project root while using src directory structure won't receive the helpful build-time validation error. Instead, they'll experience confusing runtime behavior without clear guidance on where to place their files.

The test case "should throw error when middleware is outside src directory" expects this validation to work, confirming this is a bug rather than intended behavior.

Recommendation

Change the rootDir calculation to properly search the project root directory. Replace line 1144 with:

const projectRoot = path.join((pagesDir || appDir)!, '../..')
const srcRoot = path.join((pagesDir || appDir)!, '..')
const rootDir = isSrcDir ? projectRoot : srcRoot

Or alternatively, search both locations when isSrcDir is true:

const searchDirs = isSrcDir ? 
  [path.join((pagesDir || appDir)!, '../..'), path.join((pagesDir || appDir)!, '..')] : 
  [path.join((pagesDir || appDir)!, '..')]

This ensures that when using src directory structure, the validation checks both the project root (to catch incorrectly placed files) and the src directory (to allow correctly placed files).

Analysis

The build process creates rootPaths that contain file extensions (like /middleware.js, /src/middleware.js) through this processing:

const rootPaths = Array.from(await getFilesInDir(rootDir))
  .filter((file) => includes.some((include) => include.test(file)))
  .map((file) => path.join(rootDir, file).replace(dir, ''))

However, the validation functions validateMiddlewareInSrcDir() and validateInstrumentationInSrcDir() rely on isMiddlewareFile() and isInstrumentationHookFile() which only match exact paths without extensions:

export function isMiddlewareFile(file: string) {
  return (
    file === `/${MIDDLEWARE_FILENAME}` || file === `/src/${MIDDLEWARE_FILENAME}`
  )
}

This means isMiddlewareFile('/middleware.js') returns false, causing the validation condition to never trigger. The validation works correctly in development mode because absolutePathToPage() strips file extensions, but fails during builds.

This bug means the new validation feature is completely non-functional during builds, potentially allowing users to incorrectly place middleware/instrumentation files outside the src directory when they should be required to be inside it.

Recommendation

Strip the file extension from the path before calling the validation functions. Modify the validation calls in lines 1167-1172:

if (rootPath.includes(MIDDLEWARE_FILENAME)) {
  const pathWithoutExtension = rootPath.replace(/\.[^/.]+$/, '')
  validateMiddlewareInSrcDir(pathWithoutExtension, isSrcDir)
}
if (rootPath.includes(INSTRUMENTATION_HOOK_FILENAME)) {
  const pathWithoutExtension = rootPath.replace(/\.[^/.]+$/, '')
  validateInstrumentationInSrcDir(pathWithoutExtension, isSrcDir)
}

Alternatively, update the validation functions to handle paths with extensions by modifying isMiddlewareFile and isInstrumentationHookFile to strip extensions before comparison.

Analysis

The validateMiddlewareInSrcDir and validateInstrumentationInSrcDir functions check if file paths start with /src/ using fileName.startsWith('/src/'). However, in the build process, the rootPaths are created using path.join(rootDir, file).replace(dir, '') which preserves platform-specific path separators.

On Windows systems, this creates paths like \src\middleware.js (with backslashes), but the validation checks for /src/ (with forward slashes). This means:

1. On Windows: A middleware file correctly placed in src/middleware.js will have a path like \src\middleware.js
2. The validation: !fileName.startsWith('/src/') will return true (since \src\middleware.js doesn't start with /src/)
3. Result: The validation throws SrcDirectoryError even though the file is in the correct location

This is inconsistent with the dev server code path, which uses normalizePathSep() to convert backslashes to forward slashes before validation, ensuring cross-platform compatibility.

The codebase has established patterns for handling cross-platform paths (see normalizePathSep(), ensureLeadingSlash() functions), but the new validation functions don't follow these patterns.

Recommendation

Normalize the path separators before validation to ensure cross-platform compatibility. Update both validation functions to use forward slashes consistently:

export function validateMiddlewareInSrcDir(fileName: string, isSrcDir: boolean) {
  const normalizedPath = fileName.replace(/\\/g, '/')
  if (isSrcDir && isMiddlewareFile(fileName) && !normalizedPath.startsWith('/src/')) {
    throw new SrcDirectoryError(fileName, 'middleware')
  }
}

export function validateInstrumentationInSrcDir(fileName: string, isSrcDir: boolean) {
  const normalizedPath = fileName.replace(/\\/g, '/')
  if (isSrcDir && isInstrumentationHookFile(fileName) && !normalizedPath.startsWith('/src/')) {
    throw new SrcDirectoryError(fileName, 'instrumentation')
  }
}

Alternatively, import and use the existing normalizePathSep function from shared/lib/page-path/normalize-path-sep.ts for consistency with the rest of the codebase.