You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
apps/console: three lazy page imports in AppContent.tsx are defeated by static imports in App.tsx — 3 INEFFECTIVE_DYNAMIC_IMPORT warnings per build #5467
Found while measuring #5325 for PR #5466. Same defect class as #5325, different package and outside that card's declared file surface, so filing rather than folding it in.
Every console vite build on 77f846a8b emits 46 INEFFECTIVE_DYNAMIC_IMPORT warnings. 43 are the packages/fields ones #5325 covers. The other three are the console's own:
[INEFFECTIVE_DYNAMIC_IMPORT] src/pages/DocPage.tsx is dynamically imported by
src/AppContent.tsx but also statically imported by src/App.tsx, dynamic import
will not move module into another chunk.
Same for src/pages/DocsLayout.tsx and src/pages/DocsSlug.tsx.
AppContent.tsx lazy-imports each page; App.tsx statically imports the same three, so all three are in the eager graph regardless and the import() is decoration. Someone wrote those lazy imports on purpose and the intent is dead.
I have not measured what these three pages weigh or whether removing the static import in App.tsx actually moves them out of the eager closure. That is the first step for whoever picks this up, and it is now cheap: PR #5466 makes the console build write dist/eager-closure.json (gzipped bytes per eagerly loaded chunk), so the before/after is one build each. Do not assume the answer — #5325 looked obviously worth bytes and measured at zero.
The docs pages plausibly are not on the critical path for most console page loads, which is presumably why someone lazy-loaded them in the first place.
Counter-probe before trusting any zero from that command: a build that fails early prints 0 warnings and exits non-zero. Check the exit code, not just the count — that reading cost a cycle while measuring #5325.
Found while measuring #5325 for PR #5466. Same defect class as #5325, different package and outside that card's declared file surface, so filing rather than folding it in.
Every console
vite buildon77f846a8bemits 46INEFFECTIVE_DYNAMIC_IMPORTwarnings. 43 are thepackages/fieldsones #5325 covers. The other three are the console's own:Same for
src/pages/DocsLayout.tsxandsrc/pages/DocsSlug.tsx.AppContent.tsxlazy-imports each page;App.tsxstatically imports the same three, so all three are in the eager graph regardless and theimport()is decoration. Someone wrote those lazy imports on purpose and the intent is dead.Why this is filed separately from #5325
Two reasons, and the second is the interesting one.
apps/console, notpackages/fields.packages/fields/src/index.tsxis defeated by a static import of the same module — 13+INEFFECTIVE_DYNAMIC_IMPORTwarnings per console build #5325 does not apply here.finding(fields): every lazy widget import inpackages/fields/src/index.tsxis defeated by a static import of the same module — 13+INEFFECTIVE_DYNAMIC_IMPORTwarnings per console build #5325's fix is stuck because (a) removing the barrel'sexport *is a public API change to@object-ui/fields, and (b) it buys 0 bytes anyway: theadvancedChunksgroup namedui-componentsclaims everypackages/fieldsmodule and folds it into an eagerly-imported chunk, so the laziness cannot pay off no matter what the source says (measured in finding(fields): every lazy widget import inpackages/fields/src/index.tsxis defeated by a static import of the same module — 13+INEFFECTIVE_DYNAMIC_IMPORTwarnings per console build #5325). Neither holds for these three.App.tsx/AppContent.tsxare app-internal — no published surface — andapps/console/srcis not claimed by anyadvancedChunksgroup, so a genuinely lazy page can get its own chunk.Not yet measured
I have not measured what these three pages weigh or whether removing the static import in
App.tsxactually moves them out of the eager closure. That is the first step for whoever picks this up, and it is now cheap: PR #5466 makes the console build writedist/eager-closure.json(gzipped bytes per eagerly loaded chunk), so the before/after is one build each. Do not assume the answer — #5325 looked obviously worth bytes and measured at zero.The docs pages plausibly are not on the critical path for most console page loads, which is presumably why someone lazy-loaded them in the first place.
Reproduction
Counter-probe before trusting any zero from that command: a build that fails early prints 0 warnings and exits non-zero. Check the exit code, not just the count — that reading cost a cycle while measuring #5325.