One stale app blocks a frontend-base major

[arbrandes]

Description

Apps declare frontend-base as a peer dependency with a caret range, and a site composes many of them against a single deduped copy. Since npm 7 an unsatisfiable peer range is a hard ERESOLVE failure rather than a warning, so a new frontend-base major breaks npm install for every site containing an app that has not yet been republished.

frontend-app-aspects is a live example: it still declares "@openedx/frontend-base": "^1.0.0-alpha || 0.0.0-dev", so no site that includes it can install against frontend-base 2.x until that app is republished, whether or not it uses anything 2.0 changed.

The coupling is tighter than the compatibility it describes. One version number covers the CLI, the webpack configuration, the shell runtime, and the API apps import, so a break in any of them invalidates every app's range whether or not that app touches what broke. Semver cannot express "major for sites, minor for apps", and npm's refusal to install rather than warn is a tooling decision, not a property of semver.

#307 proposes a decision.

[arbrandes]

Decided this is a non-issue. The lockstep upgrades are an explicit goal of OEP-65, for consistency.

Adventurous app authors can loosen dependency ranges if they want (frontend-base >= 1.0) and site operators can override: dependencies.