-
Notifications
You must be signed in to change notification settings - Fork 5.5k
fix(5955): ensure getEnvironment() function to return the correct environment values #38614
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
Conversation
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
8195ec3 to
bb5535f
Compare
Builds ready [bb5535f]
UI Startup Metrics (1223 ± 75 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
bb5535f to
3d520ee
Compare
Builds ready [3d520ee]
UI Startup Metrics (1220 ± 90 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
3d520ee to
c36137b
Compare
Builds ready [ec732ff]
UI Startup Metrics (1313 ± 117 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
68259ef to
143a532
Compare
| * @param {string} taskName - The task name or build target. | ||
| * @returns {BUILD_TARGETS | string} The extracted build target. | ||
| */ | ||
| function getBuildTargetFromTask(taskName) { |
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.
Child processes receive task names (e.g., scripts:core:test:standardEntryPoints) instead of build targets (test). This function extracts the correct build target from task names so getEnvironment() works correctly in child processes.
| * @param args - The parsed CLI arguments | ||
| * @returns The resolved environment string | ||
| */ | ||
| export function resolveEnvironment( |
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.
Previously, webpack just used args.test ? 'testing' : env, which meant local --env production builds would report as production to Sentry. Now:
- production is NEVER auto-detected, it must be explicitly set
- Git context is checked for proper environment detection
| if (args.dryRun) { | ||
| console.error(getDryRunMessage(args, features)); | ||
| const resolvedEnv = resolveEnvironment(args); | ||
| console.error(getDryRunMessage(args, features, resolvedEnv)); |
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.
Show the actual resolved environment in dry-run output.
143a532 to
b1516e9
Compare
Builds ready [b1516e9]
UI Startup Metrics (1277 ± 106 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Builds ready [6d9fdfb]
UI Startup Metrics (1286 ± 97 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Builds ready [b0f9784]
UI Startup Metrics (1269 ± 111 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Builds ready [86ad1cc]
UI Startup Metrics (1266 ± 125 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
|
The webpack changes look good, but the browserify changes are still a bit confusing to me. The bulk of the changes are a new function The description you gave of the problem is here:
But the manifest task is not run in a child process, it's only run in the root process. So effectively it's always correct. The browserify-based build script only uses child processes for the script tasks, the slowest ones. Technically the manifest task is created in each child processes, so if you had added logging to The changes you've made here still make the code easier to follow I think (at least now the manifest tasks in child processes will be correct, even though they're never run). But I just wanted to make sure I wasn't missing something here that would have some impact on the final build. |
|
@Gudahtt Thanks for pointing it out. And it is actually correct, after tracing through the code more carefully, I can confirm that:
I've removed those changes in this commit: 60fb0ed However, while investigating I found a real issue in The PR now focuses on:
Updated the description as well. |
Builds ready [60fb0ed]
UI Startup Metrics (1273 ± 96 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Gudahtt
left a comment
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.
LGTM!
Builds ready [0ac4bd5]
UI Startup Metrics (1248 ± 98 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Description
This PR adds proper environment detection to the webpack build system and fixes fragile build target detection in the browserify build.
Problem
Webpack: The webpack build was setting
METAMASK_ENVIRONMENTbased solely on--env, making it easy to accidentally pollute the production Sentry project with events from local or CI test builds.Browserify: The
getIgnoredFiles()function used fragile substring matching (target.includes('dev')) to determine build type. This worked by accident because task names likescripts:core:test:standardEntryPointscontain the build target as a substring, but would fail for differently named tasks.Solution
Final Result
Browserify Builds
yarn startdevdevelopmentyarn build:testtesttestingyarn test:e2e:singletestDevdevelopmentyarn distdistotheryarn build:prodprodproductionWebpack Builds
yarn webpack --env developmentdevelopmentyarn webpack --env productionotheryarn webpack --env production --targetEnvironment productionproductionyarn webpack --testtestingChangelog
CHANGELOG entry: null
Related issues
Fixes: https://github.com/MetaMask/MetaMask-planning/issues/5955
Fixes: https://github.com/MetaMask/MetaMask-planning/issues/6014
Manual testing steps
Test script for webpack builds:
Results:
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist
Note
Improves build correctness and safety by formalizing environment and build-target detection.
getBuildTargetFromTaskindevelopment/build/utils.jsand use it indevelopment/build/index.jsto reliably detect dev/test builds (replacingincludeschecks); export and test it (utils.test.ts).resolveEnvironmentindevelopment/webpack/utils/config.tsto derive MetaMask environment (testing, development, staging, release-candidate, pull-request, other) with explicit override via--targetEnvironment; wire intogetVariablesand dry-run output.--targetEnvironmentoption and enhancedgetDryRunMessagesignature/output; updatewebpack.config.tsto useresolveEnvironmentfor dry runs.development/webpack/README.md.Written by Cursor Bugbot for commit 0ac4bd5. This will update automatically on new commits. Configure here.