Skip to content

Follow-up: re-split panel chunks after lazy service-client initialization #3944

Description

@koala73

Context

PR #3943 fixed the production startup crash by collapsing all panel modules back into the single panels chunk. That was the right stability-first rollback for the ESM temporal-dead-zone cycle introduced by the panel chunk split in #3113.

The tradeoff is intentional but real: the panel chunk is still statically imported by the main entry and appears in modulepreload, so the full panel bundle downloads eagerly at boot. The current full build is roughly 2.46 MB minified, with the production preview showing about 501 KB brotli. Any one-panel edit also busts that whole chunk cache for every user.

Follow-up work

  • Lazy-initialize generated service-client singletons in panel modules instead of constructing them at module top level.
  • Reintroduce domain/variant panel chunking only after the TDZ-prone top-level imports are gone.
  • Update tests/chunk-assignment.test.mjs so it allows the intentional split while still rejecting circular chunk graphs that can crash startup.
  • Keep a production-build smoke check that catches Cannot access ... before initialization regressions.
  • Verify the main entry no longer eagerly modulepreloads the whole panel surface and that one-panel edits do not invalidate every panel chunk.

Acceptance criteria

  • npm run build:full completes without Rollup circular chunk warnings involving panel chunks.
  • Production preview opens with no startup ReferenceError.
  • Panel chunks are split by documented ownership/domain or variant boundaries.
  • Bundle output shows the initial boot path no longer eagerly downloads the complete panel bundle.

Related: #3113, #3943

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Medium priority, schedule when capacity allows

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions