Skip to content

feat(mf-host): install remotes eagerly as each resolves#254

Merged
maksimzinchuk merged 3 commits into
mainfrom
feat/mf-host-resilience
Jul 20, 2026
Merged

feat(mf-host): install remotes eagerly as each resolves#254
maksimzinchuk merged 3 commits into
mainfrom
feat/mf-host-resilience

Conversation

@maksimzinchuk

@maksimzinchuk maksimzinchuk commented Jul 7, 2026

Copy link
Copy Markdown
Collaborator

Overview

Reworks registerRemoteModules to install each remote eagerly, the moment
its loadRemote resolves, instead of collecting all results behind a
Promise.allSettled barrier and installing afterwards.

Previously the slowest remote (for example a cold dev-server compile of the
shared framework graph) held back every other module — no menu items or routes
appeared until the whole batch had loaded. Now each module lights up as soon as
it is ready; a failed remote still lands in the failed list and is reported.

Also pins the vee-validate shared version to the installed 4.15.1:
vee-validate blocks the ./package.json subpath in its exports map and exposes
no runtime version, so — unlike the other shared deps — it cannot be resolved
at build time and must be pinned (it only needs to satisfy the remotes'
requiredVersion of ^4.12.0).

Verification

  • packages/mf-host unit suite green (24 tests), including the
    start → loaded → installed → done performance-mark ordering.

Note: this supersedes the earlier time-bound manifest/load approach on this
branch — the timeout machinery and its tests were removed in favour of eager
install.

…emoteModules

Neither the manifest fetch nor loadRemote was time-bounded, so a hung
endpoint or hung remote could leave modulesReady stuck at false and hang
the loading gate forever. Add a withTimeout helper and two optional,
defaulted options (manifestTimeoutMs=5000, loadTimeoutMs=10000):

- manifest fetch is bounded via AbortSignal + withTimeout; a timeout/abort
  degrades to the existing warn+skip policy, while a real network error
  still surfaces as modulesLoadError.
- each remote load is bounded; a timed-out remote lands in the existing
  failed[] path without tripping modulesLoadError, and a late settle after
  the budget is logged.
@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

📦 Preview published for commit b982c7b

Install the preview with dist-tag:

npm install @vc-shell/framework@pr-254

Or pin to the exact commit:

npm install @vc-shell/framework@2.1.0-pr254.b982c7b

Published packages (dist-tag pr-254, version 2.1.0-pr254.b982c7b):

  • @vc-shell/framework
  • @vc-shell/api-client-generator
  • @vc-shell/create-vc-app
  • @vc-shell/config-generator
  • @vc-shell/migrate
  • @vc-shell/ts-config
  • @vc-shell/mf-config
  • @vc-shell/mf-host
  • @vc-shell/mf-module
  • @vc-shell/vc-app-skill

…d loading

Replaces the manifest/load timeout approach with eager installation: each
remote is installed the moment its loadRemote resolves, instead of waiting
behind a Promise.allSettled barrier. This stops the slowest remote (e.g. a
cold dev-server compile of the shared framework graph) from holding back every
other module's menu items and routes.

Also pins the vee-validate shared version to the installed 4.15.1, since
vee-validate blocks the "./package.json" subpath and exposes no runtime
version to resolve at build time.

Removes the manifestTimeoutMs/loadTimeoutMs/withTimeout machinery and its
resilience tests; the base test suite (24 tests) covers the eager-install path.
@maksimzinchuk maksimzinchuk changed the title feat(mf-host): time-bound manifest fetch and remote load in registerRemoteModules feat(mf-host): install remotes eagerly as each resolves Jul 17, 2026
Adds cases for the eager-install path in registerRemoteModules:
- a fast remote installs while a slower remote is still pending (no barrier)
- the summary warn reports the loaded/total count and the failed plugin ids
- one install line is logged per successfully installed remote
@maksimzinchuk
maksimzinchuk merged commit ec4a7cb into main Jul 20, 2026
9 checks passed
@maksimzinchuk
maksimzinchuk deleted the feat/mf-host-resilience branch July 20, 2026 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant