-
Notifications
You must be signed in to change notification settings - Fork 29k
fix: prioritize src/ directory for instrumentation.ts in development #82513
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: canary
Are you sure you want to change the base?
fix: prioritize src/ directory for instrumentation.ts in development #82513
Conversation
When a src/ directory exists, the development server should exclusively load instrumentation.ts from src/ and completely ignore any file in the root directory. This aligns development behavior with production. - Modified getPossibleInstrumentationHookFilenames() to check for src/ directory existence - If src/ exists, only return src/ paths; otherwise only return root paths - Fixes inconsistency where dev loaded from root even when src/ existed Co-Authored-By: Jiwon Choi <devjiwonchoi@gmail.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
if (hasSrcDir) { | ||
files.push( | ||
path.join(folder, `src`, `${INSTRUMENTATION_HOOK_FILENAME}.${extension}`) | ||
) | ||
} else { | ||
files.push( | ||
path.join(folder, `${INSTRUMENTATION_HOOK_FILENAME}.${extension}`) | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function now only returns instrumentation hook files from either the root OR src directory, but Next.js is designed to support both locations simultaneously.
View Details
Analysis
The getPossibleInstrumentationHookFilenames
function has been modified to only return file paths from one location (either root or src directory) based on whether the src directory exists. This breaks the intended functionality because:
-
Multiple functions confirm both locations should be valid: Other functions in the same file like
isInstrumentationHookFile
(lines 1776-1777) andisInstrumentationHookFilename
(lines 309-310) clearly show that instrumentation hooks are valid in both/instrumentation
and/src/instrumentation
locations simultaneously. -
Function name implies all possibilities: The function is named
getPossibleInstrumentationHookFilenames
(emphasis on "Possible"), suggesting it should return all potential locations where the files could exist. -
Original behavior was correct: The original implementation returned both paths for each extension, allowing the consumer to check all possible locations.
-
Potential missed files: If a user has instrumentation files in both the root and src directories, the new logic will only detect files in one location, potentially missing important instrumentation hooks.
The function is used in file watching scenarios where all possible paths should be monitored, not just paths from one directory.
Recommendation
Revert the logic to return both possible paths for each extension, similar to the original implementation:
export function getPossibleInstrumentationHookFilenames(
folder: string,
extensions: string[]
) {
const files = []
for (const extension of extensions) {
files.push(
path.join(folder, `${INSTRUMENTATION_HOOK_FILENAME}.${extension}`),
path.join(folder, `src`, `${INSTRUMENTATION_HOOK_FILENAME}.${extension}`)
)
}
return files
}
If optimization is desired, the file existence checking should be done by the consumer of this function, not within the function that's supposed to return all "possible" locations.
- Import existsSync from 'fs' alongside existing fs import - Remove inline require('fs') statement that was causing build conflicts - Maintains the same logic for prioritizing src/ directory when it exists Co-Authored-By: Jiwon Choi <devjiwonchoi@gmail.com>
What?
Fixes inconsistent instrumentation.ts loading behavior between development and production environments when a
src/
directory exists.Why?
Problem:
instrumentation.ts
from root directory even whensrc/
directory existsinstrumentation.ts
fromsrc/
directory when it existssrc/
whensrc/
directory exists, ignoring any root-level fileThis inconsistency causes confusion and potential issues when projects have both
instrumentation.ts
in root andsrc/instrumentation.ts
, as different files are loaded in different environments.How?
Modified
getPossibleInstrumentationHookFilenames()
inpackages/next/src/build/utils.ts
:src/
directory existence usingfs.existsSync()
src/
exists: Only return paths withinsrc/
directorysrc/
: Only return root directory pathsBefore:
After:
Testing
Created test script that validates:
src/
directory exists → only returns root pathssrc/
directory exists → only returns src pathsHuman Review Checklist
Critical items to verify:
src/
when directory existsfs.existsSync()
) is appropriate for this contextPotential risks:
fs.existsSync()
call in hot path (though just directory check)require('fs')
usage (follows existing codebase pattern)Link to Devin run: https://app.devin.ai/sessions/dd6bf37499764766864e431921c83280
Requested by: @devjiwonchoi
This change ensures consistent instrumentation.ts loading behavior across all Next.js environments.