← All writing

Technical note · 2026-09-14

Keeping remote component scripts and styles on the same release

Analyze immutable assets, release manifests and old-page lifetimes when independently delivered components are loaded by a host application.

Exploration · Principles and possible approaches inspired by a project context.

  • Component libraries
  • Static assets
  • Releases
  • Caching

Related project: Shared business component library. Independent builds motivate this exploration of remote delivery; these release mechanisms are not claimed as current deployment features.

Successful files can form an incompatible combination

New JavaScript may run with cached old CSS. A freshly replaced entry may reference chunks not yet uploaded. The delivery unit is a compatible resource set, including styles, chunks and host expectations.

Bind a version to immutable assets

One design gives every release versioned or content-hashed URLs and a manifest that binds its entry and styles. Resolve the manifest once for a page’s use of the component rather than repeatedly reading a moving “latest” pointer.

release A → entry A + styles A + chunks A
release B → entry B + styles B + chunks B

Check indirect dependencies such as fonts and images referenced by CSS. Listing an entry does not prove the full resource graph is available.

Upload first, switch second

Publish and verify all new resources before changing the active release pointer. Retain previous assets for pages that are already open and may request an old lazy chunk later.

Vite’s load-error discussion describes that stale-page failure mode. This analysis uses the model, not a version-specific error-event API.

Retention should account for page lifetime, caching and rollback needs. It is a bounded support decision, not a promise that every old page remains valid forever.

Roll back the complete set

A rollback must restore a coherent release rather than only its entry script. Incompatible host contracts or data changes may still prevent recovery, so define the supported integration range.

Expose retry or a contained failure state. Refreshing the entire host can discard unrelated unsaved work.

Keep an old page open during verification

Open release A without triggering a lazy feature, publish B, then use that feature in the old page. Exercise mismatched CSS, incomplete uploads, stale manifests and rollback.

A fresh page working after deployment is only one part of release consistency.