Performance audit finding · Severity: Medium · Effort: Medium · Fix risk: Simple (build-time only) · Test safety net: N/A (tooling)
Owner: @MetaMask/mobile-platform (suggested)
File: babel.config.js:67
What is this about?
React Compiler is fully enabled (#31171) via the bare 'react-compiler' Babel plugin — with no logger, no error categorization, and no coverage accounting. The compiler fails open: any component it can't compile is silently skipped and ships unoptimized (#30919 counted 53 class components in that bucket at enablement). Today there is no way to answer "what is the compiler actually compiling, and which of its errors are worth fixing?" without ad-hoc spelunking.
The critical triage split the logger enables: on CompileError, event.detail.options.category === 'Todo' means unsupported syntax (an unimplemented compiler feature — no actionable fix on our side), while any other category (InvalidReact, InvalidJS) is a legitimate, actionable Rules-of-React violation. Without this split, the Todo noise drowns the actionable list. (Category names verified against babel-plugin-react-compiler@1.0.0.)
Example — the extension's verbose run at enablement (metamask-extension#38007):
| Status |
Files |
| ✅ Compiled |
253 |
| ⏭️ Skipped |
0 |
| ❌ Errors (actionable) |
31 |
🔍 Unsupported (Todo) |
7,024 |
| 📦 Total processed |
7,308 |
Read without the split, this is ~7,000 hopeless "errors". Read with it, the actionable backlog is 31 files — a tractable list — while the 7,024 Todos are the compiler's backlog to burn down across upgrades, re-diffed per version bump. That is the entire value proposition of the categorized logger.
Scenario
N/A — build tooling.
Design
N/A.
Technical Details
Fix
Pass a logger in the Babel plugin options that buckets events into compiled / skipped / error / unsupported (worst-status-wins per file) and prints a summary, gated behind an env flag for opt-in verbose builds. Reference implementation: the extension's webpack integration (metamask-extension#38007, --reactCompilerVerbose / --reactCompilerDebug={all|critical|none} mapping to panicThreshold). The ratchet end-state: a non-production build that passes panicThreshold: 'critical_errors', then 'all_errors' (production stays 'none' permanently).
Threat Modeling Framework
N/A — build-time tooling; no runtime change.
Acceptance Criteria
- An env-gated build prints compiled/skipped/error/unsupported counts (file and component granularity) with
'Todo'-category errors bucketed as unsupported.
- The actionable-error list (non-
Todo) is tracked and trends down; the unsupported list is re-diffed on compiler upgrades.
References
What is this about?
React Compiler is fully enabled (#31171) via the bare
'react-compiler'Babel plugin — with nologger, no error categorization, and no coverage accounting. The compiler fails open: any component it can't compile is silently skipped and ships unoptimized (#30919 counted 53 class components in that bucket at enablement). Today there is no way to answer "what is the compiler actually compiling, and which of its errors are worth fixing?" without ad-hoc spelunking.The critical triage split the logger enables: on
CompileError,event.detail.options.category === 'Todo'means unsupported syntax (an unimplemented compiler feature — no actionable fix on our side), while any other category (InvalidReact,InvalidJS) is a legitimate, actionable Rules-of-React violation. Without this split, the Todo noise drowns the actionable list. (Category names verified againstbabel-plugin-react-compiler@1.0.0.)Example — the extension's verbose run at enablement (metamask-extension#38007):
Todo)Read without the split, this is ~7,000 hopeless "errors". Read with it, the actionable backlog is 31 files — a tractable list — while the 7,024
Todos are the compiler's backlog to burn down across upgrades, re-diffed per version bump. That is the entire value proposition of the categorized logger.Scenario
N/A — build tooling.
Design
N/A.
Technical Details
Fix
Pass a
loggerin the Babel plugin options that buckets events into compiled / skipped / error / unsupported (worst-status-wins per file) and prints a summary, gated behind an env flag for opt-in verbose builds. Reference implementation: the extension's webpack integration (metamask-extension#38007,--reactCompilerVerbose/--reactCompilerDebug={all|critical|none}mapping topanicThreshold). The ratchet end-state: a non-production build that passespanicThreshold: 'critical_errors', then'all_errors'(production stays'none'permanently).Threat Modeling Framework
N/A — build-time tooling; no runtime change.
Acceptance Criteria
'Todo'-category errors bucketed as unsupported.Todo) is tracked and trends down; the unsupported list is re-diffed on compiler upgrades.References
babel.config.js:67panicThresholdin non-prod builds:critical_errors, thenall_errors#31507 (thepanicThresholdratchet burns down the actionable-error list this logger produces)reactCompilerLoaderWrapper.ts,ReactCompilerPlugin)mms-performanceskill,mm-react-compiler-error-triage(perf: Augmentmms-performancewith frontend learnings from the Extension performance audit skills#49)