Skip to main content

Iris Apps — content owns padding from @trackunit/iris-app 2.5.12 (Asset Home / Site Home / Admin)

Manager is moving content inset for Asset Home, Site Home, and Admin extension iframes onto each app. After you upgrade @trackunit/iris-app to 2.5.12 or later, the host stops applying its transitional 1rem inset. Your extension must pad itself with p-content-space on the scrollable content region (or intentionally stay edge-to-edge).

Run the automated migration before or as part of that SDK upgrade — not as optional cleanup afterward. It ships as v2-5-12-p-content-space-codemod with @trackunit/iris-app 2.5.12.

npx nx g @trackunit/migrations:migrate
npx nx g @trackunit/migrations:run-migrations

Why this changed​

The host used to pad those three extension iframes for you. That fought flush headers, side-panel layouts, and correct scrollbars. Content now owns its own inset via p-content-space — the same utility host pages use. Fleet and Customer Home were always flush and are unaffected by inset removal (they still get the page-content → p-content-space class swap if you use page-content).

When it affects you​

Nothing changes until you rebuild and publish with @trackunit/iris-app 2.5.12 or later. That release is the content-inset cutoff: at or above it, Asset/Site/Admin hosts apply no inset, regardless of whether you have added your own padding. Upgrading without adopting p-content-space on those surfaces makes the pages go edge-to-edge. The Iris App build prints a warning if the cutoff is crossed and the app source does not reference p-content-space.

Apps that never rebuild keep the host inset until 2027-08-20. After that sunset date the host applies none, even if the app was built against an older SDK.

If you already self-pad with p-content-space, you are unaffected by inset removal.

What the migration does​

  • Rewrites known page-content patterns to overflow-auto p-content-space (slightly less padding on large viewports than the old responsive step-up — flat 1rem).
  • Invents or converts p-content-space on high-confidence inventable overflow content shells.
  • Never edits your manifest.
  • Reports surfaces it cannot safely resolve instead of guessing.

Inventable overflow content shell​

Auto-invent only runs when the migration can point at one clear page box — the scroll owner inside the iframe (the same region the host used to inset):

  1. A div / main / section with an editable className (not a bare design-system Card or opaque custom root).
  2. That element itself owns scrolling (overflow-auto / overflow-y-auto / scroll).
  3. One candidate — not multi-route graphs with competing shells, and not a shell that also hosts PageHeader / Topbar / Header (headers stay flush; pad the body below).

If invent cannot find that shape, console output lists the extension and explains why. That is normal for card-only UIs, multi-route apps, and intentional full-bleed surfaces. Add p-content-space manually on the correct scroll owner, or keep the surface edge-to-edge on purpose.

Incidental padding-size note​

Even Fleet/Customer-only apps that use page-content will see the class swap’s flat 1rem (and explicit overflow-auto) instead of the old responsive 1rem → 1.5rem step. That is independent of inset removal.