fix(plugin-list): ListView's columns-only fallback stops reading undeclared relational keys off a list column

[objectstack-fleet]

Fixes #7531
Clause-②: no

What changed

Until the object definition loads, ListView builds its filter and sort candidates from the view's declared columns (the !objectDef?.fields branch of the candidateFields memo). That branch read f.reference_to || f.reference, f.display_field || f.reference_field and f.id_field off each column, and ListColumnSchema declares none of them in either casing. The card's ruling (comment 5809501335, letter remove) takes the three reads out. The fallback candidate now carries only what a column declares. The relational target arrives with the object definition through the objectDef.fields branch, which this PR leaves untouched.

• packages/plugin-list/src/ListView.tsx: removes the three properties. The objectui#7642 census comment above them becomes one line that points at this card. Nothing else in the file changes.
• packages/plugin-list/src/__tests__/ListView.columnsOnlyRelationalReads-7531.test.tsx: the pin and its two lit controls.
• .changeset/7531-listview-column-undeclared-reads.md: patch on @object-ui/plugin-list.

Stop condition: the producer census (run before deleting)

Method. The census was an AST walk. The file list and the file contents both came from the same git ref (git ls-tree -r and git cat-file --batch), never from a worktree:

• objectui at 6881e9e47 (this branch's base).
• The sibling objectstack at bc80e1626 (its origin/main when this ran).

The walk parsed these kinds of file:

• .ts .tsx .js .jsx .mjs .cjs .mts .cts, using the TypeScript compiler API;
• .json and .yaml, parsed whole;
• fenced json / yaml / ts / js blocks inside .md / .mdx.

What counted as a column object. An object literal that is an element of an array bound to any of:

• a columns property;
• a columns JSX attribute;
• a columns = [...] assignment;
• a variable named like cols / columns, or typed with a Column type.

The census looked for eight spellings on those objects: reference_to, reference, display_field, reference_field, id_field, referenceTo, displayField and idField. It also listed two wider shapes:

• Any object literal that carries field plus one of the eight, wherever it sits. This catches columns built by a map.
• Any non-test object literal that carries field plus a spread. This catches keys that could arrive at runtime.

Controls.

• Population control: known column keys must hit in the same walk. field hit 460 column objects in objectui and 435 in objectstack. width hit 27 in objectui and 41 in objectstack. The walk found 956 column objects in objectui and 515 in objectstack.
• Detector control: a throwaway repo with one column carrying a target key in each carrier. The carriers were a TS property, a JSX columns attribute, a cols variable, JSON, YAML, a Markdown json block and a Markdown ts block. The walk hit 7 of 7.

Results

repo	column objects carrying one of the eight	what they are
objectstack bc80e1626	0	none
objectui 6881e9e47	4	3 line-item grid columns, 1 grid-view test fixture

• apps/console/src/dev/DevLookup.tsx, docs/adr/0001-master-detail-subform.md (the record:line_items example) and packages/fields/src/widgets/GridField.test.tsx are line-item grid columns (GridField / LineItemsField). That is a different contract: its columns are shaped like field defs, and GridField reads c.reference, c.displayField and c.idField off them on purpose. They are not list columns.

• packages/plugin-grid/src/__tests__/ObjectGrid.linkCellAnchor.test.tsx is a grid-view column carrying reference_to: 'crm_account'. That makes it the one list-column hit. It is classified as not a producer, for three reasons:

  • It is an inline input to a unit test that renders ObjectGrid directly, so ListView's fallback never sees it.
  • No ObjectGrid code reads a relational key off a column. The lookup cell takes its target from the object definition's field, through applyRelationalMeta(fieldMeta, objectDefField).
  • The fixture supplies no object definition, so the key reaches nothing, with or without this PR.

  ⚠️ If the stop condition is meant to count any fixture, this PR should be closed. See the note at the end of this body.

• None of the wider shapes found a list-column producer. The field plus relational key matches were form section fields, action and bulk-action params, a form field schema and an engine log record. The spread matches (including the 8 spread column literals in objectui) carry none of the eight spellings.

• Not measured: objectstack-ai/cloud. That repo cannot be read from this container. It was not censused, and this PR makes no claim about it.

Downstream readers of the three keys (measured)

• Sort: the sortFields memo reads only value, label and type from each candidate. It never read the three keys, so sorting is unaffected.
• Filter: FilterBuilder draws its remote LookupValuePicker only when the field is lookup-like, has no static option domain, and has a referenceTo (or type === "user"). The picker then reads displayField (default "name") and idField (default "id").
• Spec-shaped columns see no change. A column that ListColumnSchema parses cannot carry any of the five read spellings (the pin's first case asserts this against the installed spec). So all three values were already undefined for such a column. The plain-column control stays green with the reads put back (see the ablation below). Once the definition loads, the objectDef.fields branch supplies referenceTo. The third case asserts this, and it passes with and without the reads.

Pin, and the ablation that proves it can fail

The pin holds getObjectSchema pending on purpose, so the columns-only branch is the only one that runs. It captures the candidate list ListView hands to FilterBuilder, using a vi.mock that inherits the real module and overrides only FilterBuilder. The four cases:

1. The spec refuses each of the five spellings on a column (unrecognized_keys). Control: the bare column parses.
2. Control: a plain column gives the columns-only candidate list (account_id / Account / lookup, then name / Name / text), with no referenceTo.
3. Pin: a column carrying the five keys gives a candidate list that toStrictEquals the plain one, with referenceTo, displayField and idField all undefined.
4. Control: when the definition resolves with reference: 'crm_account', the candidate shows referenceTo: 'crm_account'. This proves the capture sees the key when one exists.

Ablation, on HEAD 086e71456. The three reads were put back with node ../objectstack/scripts/ablation-replace.mjs in wrap mode, holding the verify lock:

• Mutation on disk: anchor count 1 → 0; ListView.tsx blob 03798ad2b3be → 39feb0e2facd; count of the restored read line in the file = 1.
• Result: Tests 1 failed | 3 passed (4). Only the pin went red:

  -     "displayField": undefined,
  -     "idField": undefined,
  +     "displayField": "name",
  +     "idField": "id",
  -     "referenceTo": undefined,
  +     "referenceTo": "account",
  

• Restore: blob after restore 03798ad2b3be equals the HEAD blob, and git diff HEAD on the file is empty.
• Resolution path: the test imports ../ListView (source), so the mutated file is what ran. No dist/ is in that path, so no rebuild was needed for either leg.
• The first attempt did nothing: the tool refused it because the replacement text still contained the anchor, so the anchor count could not drop. No test ran, and the tool restored and verified the file. The run above is the second attempt, with a corrected anchor.

Verification (HEAD 086e71456)

• pnpm exec vitest run packages/plugin-list/ from the repo root: Test Files 93 passed (93), Tests 1098 passed (1098).
• pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-list^...' build (12 packages built; Scope: 13 of 47), then pnpm --filter @object-ui/plugin-list type-check (tsc --noEmit && tsc -p tsconfig.test.json): exit 0. tsc -p tsconfig.test.json --listFiles includes the new test.
• pnpm check:control-bytes: OK.
• pnpm check:new-line-citations: 0 new citations.
• node scripts/check-changeset-presence.mjs: ✅, one changeset declared.
• pnpm check:changeset-claims: 7 pending changesets name ListView.tsx. All were read. They cover gantt, kanban, userActions and sort-comment changes, none describes the candidate fallback's relational reads, and all stay true.
• These gates all exit 0: vi.mock inherit / specifiers / override-shape, check-test-path-roots, changeset fixed / no-major / overwrite, check:spec-symbols, check:unreferenced-sources, check:phantom-deps, check-type-check-coverage and check-lint-coverage.
• eslint on the touched files:
  • ListView.tsx: 0 errors and 183 warnings, with per-rule counts identical to the base file (checked through --stdin at the same path).
  • The new test: 0 errors and 0 warnings.
  • eslint.config.js has no type-aware linting (no parserOptions.project or projectService), so this diff cannot change the verdict on any file it did not touch. The full pnpm lint is left to CI.

Acceptance notes

• Stop condition, and one call for the reviewer. The ruling says to stop if a producer puts one of these keys on a list column. The census found no producer. It did find one list-column fixture: the plugin-grid test above. I read that fixture as not a producer, for the reasons given in the census section. If the ruling is meant to count any fixture, close this PR. The fix is then either to drop the inert key from that fixture or to rule it out explicitly, and removing the reads becomes a fresh dispatch.
• A comment made stale here and left alone on purpose. The objectDef.fields branch's comment still says "The SIBLING branch above (the schema.columns fallback) is NOT narrowed … That is a different question and is filed, not answered here." After this PR the sibling reads none of those keys. The dispatch fenced every other line of ListView.tsx, so that comment is untouched. The domain:ui seat's planned same-file docblock edits (after objectui#10534 lands) are the natural place to cut it.
• Inert fixture key, not filed. In ObjectGrid.linkCellAnchor.test.tsx, the case "a lookup column pointing at ANOTHER object stays plain" passes no matter what the column carries. The column's reference_to is read by nothing, and the fixture has no object definition. This is a test-quality note, and it has no carrier.
• Two out-of-scope findings are reported to the seat for filing (neither is changed here):
  • The objectDef.fields branch reads display_field / reference_field / id_field, but not the spec's displayField. A probe showed that a definition field carrying only displayField gives a candidate with no displayField.
  • The columns-only fallback also reads f.options, which ListColumnSchema refuses.

Session: https://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNC (the domain:ui seat's dispatch of objectui#7531).

---

Generated by Claude Code

[github-actions]

changeset-claim-re-read

⚠️ 7 pending changeset(s) describe a file this change touches

Their bodies publish verbatim into the CHANGELOG at the next release, so this is a request to re-read them against your diff — addressed here because you are the one seat that can answer it without re-deriving anything.

⛔ Nothing here blocks, and nothing here is a verdict on your change. This gate exits 0, is not a required context, and judges name resolution, never meaning: it asked whether a pending body names a file you touched. "Is this sentence still true?" is the one question it will not answer, and the one you are being asked to answer.

.changeset/7070-no-invented-gantt-date-fields.md

• names plugin-list/src/ListView.tsx → packages/plugin-list/src/ListView.tsx — edited by this change

  • app-shell/src/views/ObjectView.tsx — the console object page. The inline branch becomes ganttViewOptions, the sibling of calendarViewOptions and timelineViewOptions: the declared block spread whole, title floored at 'name', no date field invented. - plugin-list/src/ListView.tsx — the render branch AND the capability gate. - plugin-view/src/ObjectView.tsx — generateViewSchema, the authored object-view element route, which bypasses ListView entirely.

.changeset/7499-gantt-non-axis-floors-omitted.md

• names plugin-list/src/ListView.tsx → packages/plugin-list/src/ListView.tsx — edited by this change

  • plugin-list/src/ListView.tsx — the object-gantt render branch. - plugin-view/src/ObjectView.tsx — generateViewSchema, the authored object-view element route, which bypasses ListView entirely.

.changeset/7773-kanban-adapter-groupfield-write.md

• names ListView.tsx → packages/plugin-list/src/ListView.tsx — edited by this change

  Who is NOT affected — the boundary is node-local. Every VIEW-LEVEL groupField read is untouched and still live: it is a legacy alias of the spec's groupByField on the kanban view config, mapped by normalize-list-view.ts, and both adapters still resolve lanes through it (ObjectView.tsx's kanbanCfg.groupField ||, ListView.tsx's groupByField || groupField). Authoring options.kanban.groupField on a list-view or object-view keeps working exactly as documented in packages/plugin-list/README.md. groupField is dead only on the generated object-kanban NODE.

.changeset/7780-object-kanban-record-source.md

• names ListView.tsx → packages/plugin-list/src/ListView.tsx — edited by this change

  groupBy is untouched and stays REQUIRED (objectui#7322, PR feat(types): declare ObjectKanbanSchema.groupBy and .limit, retire groupField on both faces (objectui#7322 item 1) #7774). A record source and a lane key are different questions: every lane-less document above is still refused at groupBy, and the two readings PR feat(types): declare ObjectKanbanSchema.groupBy and .limit, retire groupField on both faces (objectui#7322 item 1) #7774 excluded from counting as a lane-less mode — the dataSource json fragment in content/docs/utilities/data-objectstack.mdx and ListView.tsx's runtime-generated node — are asserted still-refused in the new pin. The retired groupField tombstone is likewise still refused by name.

.changeset/8990-object-kanban-groupby-optional.md

• names packages/plugin-list/src/ListView.tsx → packages/plugin-list/src/ListView.tsx — edited by this change

  • packages/plugin-list/src/ListView.tsx generates the node as groupBy: laneField. objectDef loads asynchronously, so laneField is undefined on every load until it lands, and stays undefined whenever the object offers no stageField hint and none of status / stage / state / phase. The renderer serves that node; both published faces refused it. - content/docs/utilities/data-objectstack.mdx documents an object-kanban node that is exactly { type, dataSource }, with no groupBy. ⚠️ This one is weaker and is cited for what it is: that fragment is still refused after this change, at RECORD_SOURCE_REQUIRED, because dataSource is not a rung of the record-source ladder. It shows a lane-less board is a documented authoring; it is not a document this change admits.

.changeset/list-user-actions-collision-5398.md

• names ListView.tsx → packages/plugin-list/src/ListView.tsx — edited by this change

  The harvest now reads the object block only. Both userActions read sites in ListView.tsx carry a comment naming the collision, and __tests__/ListView.userActionsCollision.test.tsx pins each clause of it: the two shapes, a producer that manufactures the view one, the harvest's blindness to it, and the projection that must keep the object's operand with a toolbar block — or an empty block — present on the view.

.changeset/listview-comment-pair-4559.md

• names ListView.tsx → packages/plugin-list/src/ListView.tsx — edited by this change

  Two comment corrections in ListView.tsx (objectui#4559, objectui#4966). No runtime behaviour changes and the emitted bundle is byte-identical; the published .d.ts does change, which is why this is a patch rather than an empty frontmatter.

Read the paragraph, not the line: both false halves of the objectui#8617 claim sat in one paragraph, and correcting either alone would have left it asserting the same wrong thing.

If a claim did go false, correct the body. That is precedented and prose-only, frontmatter untouched; check-changeset-overwrite.mjs will report the correction as its own case 2 ("correcting a declaration on purpose … legitimate"), which is the intended shape — one gate asks for the read, the other records the write.

Not covered, stated so nobody reads this as more: a born-false claim that spells no line address at all (objectui#9495 coordinated one by ORDINAL — "a grep finds that member first" — and deciding that means reading what the sentence means), a claim spelled as a symbol or a package rather than a backticked file name, and a file named ambiguously.

Compared the checked-out tree with db3896c4c (merge-base with origin/main): 2 file(s) changed outside .changeset/, read against 1434 pending declaration(s) that publish a body (2016 pending in total). · run

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 329 chunks)	3046.3 KB	3104.5 KB
Main entry chunk (gzip)	147.8 KB	350 KB
Entry file	index-M2e8iTru.js	—
Status	PASS	—

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (consoleActionDispatch.js)	0.20KB	0.19KB
app-shell (index.js)	16.68KB	6.20KB
app-shell (runtime-config.js)	20.68KB	7.36KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	10.06KB	3.86KB
auth (ActiveOrganizationStorage.js)	27.95KB	10.04KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	2.07KB	1.00KB
auth (AuthProvider.js)	40.18KB	10.59KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.15KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.65KB	2.22KB
auth (SocialSignInButtons.js)	9.61KB	3.89KB
auth (UserMenu.js)	3.41KB	1.23KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.21KB	10.80KB
auth (createAuthenticatedFetch.js)	8.52KB	3.45KB
auth (index.js)	3.63KB	1.64KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.30KB	1.02KB
auth (useWorkspaceAdminStatus.js)	11.08KB	4.58KB
collaboration (CommentThread.js)	27.13KB	7.95KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.68KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	544.97KB	130.34KB
core (index.js)	9.22KB	3.71KB
create-plugin (index.js)	27.94KB	9.51KB
data-objectstack (index.js)	223.86KB	62.25KB
fields (index.js)	257.16KB	65.08KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (builtinAggregateLabels.js)	0.86KB	0.49KB
i18n (currency.js)	2.59KB	1.22KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	8.87KB	3.64KB
i18n (index.js)	5.24KB	2.27KB
i18n (pickLocalized.js)	9.86KB	3.95KB
i18n (provider.js)	39.40KB	12.91KB
i18n (useDisplayLocale.js)	3.52KB	1.76KB
i18n (useObjectLabel.js)	34.34KB	9.17KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	39.28KB	11.09KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.75KB
mobile (index.js)	1.99KB	0.87KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	6.62KB	2.45KB
mobile (useResponsive.js)	0.72KB	0.42KB
mobile (useSpecGesture.js)	5.52KB	2.10KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	13.52KB	4.88KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	6.24KB	2.16KB
permissions (discardProofCache.js)	1.04KB	0.55KB
permissions (evaluator.js)	8.33KB	3.07KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	4.83KB	2.27KB
plugin-ai (index.js)	16.01KB	3.93KB
plugin-calendar (index.js)	51.38KB	14.60KB
plugin-charts (index.js)	74.95KB	20.88KB
plugin-chatbot (index.js)	198.36KB	47.20KB
plugin-dashboard (index.js)	133.50KB	35.37KB
plugin-designer (index.js)	216.25KB	44.39KB
plugin-detail (index.js)	232.25KB	61.40KB
plugin-editor (index.js)	2.23KB	1.05KB
plugin-form (index.js)	146.50KB	37.51KB
plugin-gantt (index.js)	169.64KB	41.92KB
plugin-grid (index.js)	215.49KB	58.91KB
plugin-kanban (index.js)	49.30KB	15.39KB
plugin-list (index.js)	114.43KB	28.26KB
plugin-map (index.js)	23.82KB	7.42KB
plugin-markdown (index.js)	13.88KB	4.80KB
plugin-report (index.js)	43.55KB	11.99KB
plugin-timeline (index.js)	30.64KB	8.94KB
plugin-tree (index.js)	10.52KB	3.69KB
plugin-view (index.js)	88.00KB	21.97KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.66KB	3.50KB
providers (index.js)	0.45KB	0.23KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	4.47KB	1.63KB
react (SchemaRenderer.js)	114.58KB	37.60KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	4.03KB	1.86KB
react (schema-input.js)	4.25KB	2.04KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (body-dialect.js)	4.78KB	2.09KB
sdui-parser (codegen.js)	6.58KB	2.74KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	5.78KB	2.56KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (kanban-quick-add.js)	3.89KB	1.87KB
sdui-parser (parse.js)	25.28KB	7.80KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	18.27KB	6.20KB
types (ai.js)	4.11KB	2.06KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	1.00KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	2.93KB	1.49KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	3.75KB	1.85KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.85KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (expression.js)	0.20KB	0.18KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-inflight.js)	8.87KB	3.73KB
types (http-retry.js)	4.32KB	2.02KB
types (icon-key-migration.js)	4.26KB	1.63KB
types (index.js)	4.74KB	2.25KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	5.00KB	2.39KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (select-option.js)	0.20KB	0.19KB
types (spec-report.js)	5.05KB	1.93KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (strict-authoring-face.js)	17.15KB	6.32KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	8.11KB	3.32KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped