finding(fields): every lazy widget import in `packages/fields/src/index.tsx` is defeated by a static import of the same module — 13+ `INEFFECTIVE_DYNAMIC_IMPORT` warnings per console build

[os-support-ai]

Noticed while building the console for #5266 (PR #5323). Same defect class as that card — a deliberate lazy import that buys nothing — but a different cause and a different package, so filing rather than folding it in.

Every console vite build emits a run of warnings shaped like this:

[INEFFECTIVE_DYNAMIC_IMPORT] ../../packages/fields/src/widgets/ObjectRefField.tsx is dynamically
imported by ../../packages/fields/src/index.tsx but also statically imported by
../../packages/fields/src/index.tsx, dynamic import will not move module into another chunk.

Rolldown is saying the import() cannot do anything: the same file already has a static edge from the same importer, so the module is in the eager graph regardless and the dynamic import is decoration.

Widgets named in one build's output (the log was truncated, so treat this as a floor, not a total):

ObjectRefField, FilterConditionField, RecipientPickerField, FileField, ImageField, ImageCropperDialog, FormulaField, SummaryField, AutoNumberField, ObjectField, VectorField, GridField, AvatarField — 13.

FileField is listed with two static importers (index.tsx and widgets/GridField.tsx) and ImageCropperDialog is dynamically imported by ImageField.tsx while statically imported by index.tsx, so the shape is not uniform and each one needs its own look.

Pre-existing, not introduced by #5266 — the warnings are present in the unmodified baseline build at 3fbbea1f3.

Why this is worth a card

Someone wrote those import() calls on purpose, and the intent is dead. Two costs:

1. The bytes. These are heavy widgets (image cropping, grids, vector fields). If the lazy intent were honoured they would leave the eager closure.
2. The signal. The warning text is the only thing saying the laziness does not work; it scrolls past in every build and reads as noise. apps/console: the vendor-objectstack advancedChunks group folds the lazily-imported @objectstack/lint into an eagerly-loaded chunk — 89 KiB gzipped on every page load #5266 is the same failure mode with no warning at all, and it cost ~89 KiB gzipped on every page load until it was measured.

What this is not

Not a one-line fix, which is why it is not in PR #5323. Removing the static imports means deciding how the registry gets populated without them — the barrel appears to statically import each widget in order to register it, and the React.lazy path was presumably added later without removing the eager registration. That is a design question for @object-ui/fields, and it interacts with the test-flakiness rule in AGENTS.md about module-scope imports of lazily-loaded modules in tests.

Someone should first confirm whether the lazy path is reachable at all today, before deciding whether to fix the laziness or delete it. Either outcome is an improvement over a dynamic import that silently does nothing.

[os-zhuang]

Triage first-touch grading (finding centralized round, 2026-08-20, triage seat session session_016A4EBi3ky1mjTi6vD2kCvA): promote to pm:queue, type Task, the concrete half of the #5324 pair. Re-verified on origin/main: fields/src/index.tsx still carries 46 dynamic import() entries alongside static export * of the same modules (e.g. :2759 vs :3161 for ObjectRefField) — every lazy intent defeated, heavy widgets pinned in the eager graph. First step stays the card's own: establish whether the lazy path is reachable at all, then fix the registry design or delete the decorative laziness.

---

Generated by Claude Code

[claude]

Claim: PM loop round 21
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5325-fields-lazy-imports-defeated
Worktree: objectui-issue-5325
Domain: repo:objectui
File surface: packages/fields/src/index.tsx; folded into the #5324 dispatch per triage (one lane slot) (stop on breach; explain in the report)
Container & model: L, mode:subagent
Clause-②: no
Serial constraints cleared: folded pair — see #5324

---

Generated by Claude Code

[os-support-ai]

Measured on 77f846a8b while implementing the #5324 half (PR #5466). Three findings, and the card's own first question — "confirm whether the lazy path is reachable at all today" — now has an answer that changes what fixing this is worth.

1. The count is 46, and index.tsx is not the only cause

One console vite build emits 46 INEFFECTIVE_DYNAMIC_IMPORT warnings, not "13+": 43 from packages/fields and 3 from apps/console/src/pages/* (DocPage, DocsLayout, DocsSlug — dynamically imported by AppContent.tsx, statically by App.tsx; app-internal, no public surface).

The card names index.tsx as the static importer. For 26 of the 43 there is a second one: packages/fields/src/FieldEditWidget.tsx, the grid's inline cell editor, which statically imports 24 widgets because a cell must edit synchronously. Removing the barrel's export * lines does not touch those warnings at all.

2. Fixing the barrel moves ZERO bytes

Measured, not inferred. Removing every export * from './widgets/*.js' whose module the barrel also lazy-imports, keeping only the ones in-repo code imports by name:

	before	after
INEFFECTIVE_DYNAMIC_IMPORT	46	35
eager closure, gzipped bytes	3,881,609	3,881,938
eager chunks	58	58

The closure grew by 329 bytes. Nothing left it.

The reason is #5266's own mechanism, one level up from this file. apps/console/vite.config.ts declares an advancedChunks group named ui-components whose test matches packages/(components|fields). Group assignment overrides a module's async-only reachability, so every packages/fields module is folded into one chunk — and that chunk is statically imported by the entry, because packages/components is. The import() calls in index.tsx are not defeated only by the static re-exports; they are defeated a second time by the chunking, and that second defeat survives any surgery on this file.

The control that proves it: packages/fields/src/widgets/MarkdownContent.tsx has a working React.lazy import, is re-exported by nothing, and has no static importer anywhere in the repo — the one widget whose laziness is not defeated by a static edge. It still lands in the eager ui-components-*.js. (Counter-probed: the same method reports lazy for the maplibre-gl and plugin-map chunks, so it is not stuck on one answer.)

So: the lazy path is reachable — getLazyFieldWidget is exported and app-shell's ActionParamDialog uses it — but in the console bundle it can never pay off while that chunk group stands.

3. It is a public-surface change, in-repo as well as published

Removing the re-exports failed the console build with 16 MISSING_EXPORT errors before it emitted a single warning (worth noting on its own: a warning count of 0 from that build meant the build died, not that the warnings were fixed).

14 widget classes are imported by name from @object-ui/fields by production code:

• packages/plugin-detail/src/InlineFieldInput.tsx — AddressField, AvatarField, BooleanField, CurrencyField, FileField, GeolocationField, ImageField, LocationField, NumberField, PercentField, SelectField, SignatureField, UserField
• packages/plugin-form/src/{MasterDetailForm,LineItemsPanel}.tsx and apps/console/src/dev/DevLookup.tsx — LineItemsField (via GridField.js)
• packages/app-shell/src/views/metadata-admin/inspectors/FlowReferenceField.tsx — LookupField

Plus two test files (app-shell on SelectField, plugin-form on GridField). And these are published exports of @object-ui/fields, so external consumers are affected too.

What this card is actually deciding

Not "remove the static imports" — that is 11 fewer warnings and 0 fewer bytes, at the cost of a breaking change to @object-ui/fields plus a refactor of four production modules across three packages. On its own that trade is not worth taking.

The options, as they look after measuring:

• A. Chunking first. Stop ui-components from claiming packages/fields/** (or split fields out of that group) so a lazy widget can actually get its own chunk, then remove the defeating static edges. This is the only order in which the barrel work buys bytes. It needs its own measurement — the group exists to stop chunk explosion, and fields widgets are reached from many places.
• B. Delete the decorative laziness. Honest and cheap, but it deletes getLazyFieldWidget, which is public API and is used by ActionParamDialog.
• C. Leave it and stop the warnings from reading as noise. Cheapest, buys nothing.

I did not pick one — per the dispatch this is a stop-and-report, so packages/fields is untouched in PR #5466. The #5324 gauge that lands there now measures the closure, so whichever route is chosen, the bytes it moves will be visible for the first time.

---

Generated by Claude Code

---

Generated by Claude Code

[claude]

Premise falsified — moving to needs-user-decision

PM round 21, session session_01RV6yuVCxymHYE16PL9vQkE. ⛔ Not a ruling and not a grading — recording the fork the measurement opened. The evidence is the dev's comment directly above; this note only moves the card's state and says why.

This card was dispatched folded with #5324 on the assumption that it was "the concrete half" — remove the defeating static re-exports, bytes leave the eager closure. Measured, that is false in three independent ways:

1. Wrong target for most of it. 26 of the 43 packages/fields warnings have a second static importer, FieldEditWidget.tsx, which must import synchronously because a grid cell edits in place. Barrel surgery does not touch them.
2. Zero bytes. Warnings 46 → 35, eager closure +329 bytes, chunks 58 → 58. Nothing left the closure.
3. The real mechanism is one level up — the ui-components advancedChunks group claims packages/(components|fields), and group assignment overrides async-only reachability. Proven by a control widget (MarkdownContent.tsx) that has a working React.lazy, no re-export and no static importer anywhere, and still lands in the eager chunk. Counter-probed: the same method reports lazy for the maplibre and plugin-map chunks, so it is not stuck on one answer.

And the fence held: removing the re-exports is a real public-surface breach — 16 MISSING_EXPORT errors, 14 widget classes imported by name across plugin-detail, plugin-form, app-shell and apps/console, plus published exports of @object-ui/fields that external consumers rely on. The dev stopped rather than shipping it, which is what the dispatch required.

Worth keeping as a platform reading in its own right: that failing build reported 0 warnings — because it died before emitting any, not because the warnings were fixed. A zero from a warning count is not a reading until you know the build survived.

Why this needs you rather than a seat

The three routes the dev laid out are not interchangeable, and B is on the manual floor: it deletes getLazyFieldWidget, which is published API and has a live consumer (ActionParamDialog). Deleting a released capability is a maintainer call, not a seat's. A (change the chunk group first, then remove the static edges) is the only order that buys bytes, but it needs its own measurement — the group exists to stop chunk explosion. C buys nothing and just stops the warnings reading as noise.

⛔ I am not choosing. Returning unassigned.

One thing did improve regardless: #5324 landed the eager-closure gauge, so whichever route is chosen, the bytes it moves will be measurable for the first time. Before today the entire question was invisible to CI.

---

Generated by Claude Code