feat(mf-host): install remotes eagerly as each resolves#254
Merged
Conversation
…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.
|
📦 Preview published for commit Install the preview with dist-tag: npm install @vc-shell/framework@pr-254Or pin to the exact commit: npm install @vc-shell/framework@2.1.0-pr254.b982c7bPublished packages (dist-tag
|
…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.
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
Reworks
registerRemoteModulesto install each remote eagerly, the momentits
loadRemoteresolves, instead of collecting all results behind aPromise.allSettledbarrier 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
failedlist and is reported.Also pins the
vee-validateshared version to the installed4.15.1:vee-validate blocks the
./package.jsonsubpath in its exports map and exposesno runtime
version, so — unlike the other shared deps — it cannot be resolvedat build time and must be pinned (it only needs to satisfy the remotes'
requiredVersionof^4.12.0).Verification
packages/mf-hostunit suite green (24 tests), including thestart → loaded → installed → doneperformance-mark ordering.