@eclipse-glsp/cli 2.9.0-next.2 → 2.9.0-next.4

package/README.md

@@ -22,7 +22,7 @@ Options:
 
 Commands:
   checkHeaders [options] <rootDir>      Validates the copyright year range (end year) of license header files
-  updateNext|u [options] [rootDir]      Updates all `next` dependencies in GLSP project to the latest version
+  updateNext|u [options] [rootDir]      Updates all pinned `next` dependencies in a GLSP project to the currently published 'next' versions
   generateIndex [options] <rootDir...>  Generate index files in a given source directory.
   releng                                Commands for GLSP release engineering (Linux only, intended for CI/Maintainer use).
   repo                                  Multi-repository management for GLSP projects
@@ -62,11 +62,20 @@ Options:
 
 ## updateNext
 
+The `updateNext` command updates the cross-repo GLSP nightly dependencies of a downstream repository
+(e.g. the Theia or VS Code integration). Since GLSP nightlies are published as consistent exact-pinned
+sets, downstream repositories pin them explicitly too: every `@eclipse-glsp/*` / `@eclipse-glsp-examples/*`
+dependency with an exact next version (e.g. `2.9.0-next.3`) is rewritten in the `package.json` files to
+the version currently published under the `next` dist-tag, followed by a `pnpm install` to reconcile the
+lockfile. Every nightly bump is therefore an explicit, reviewable manifest diff. Legacy literal `next`
+(dist-tag) ranges are migrated to exact pins on the first run; exact next versions of non-GLSP packages
+are left alone.
+
 ```console
 $ glsp updateNext -h
 Usage: glsp updateNext|u [options] [rootDir]
 
-Updates all `next` dependencies in GLSP project to the latest version
+Updates all pinned `next` dependencies in a GLSP project to the currently published 'next' versions
 
 Arguments:
   rootDir        The repository root (default: "<cwd>")
@@ -207,7 +216,9 @@ always forms one consistent, reproducible set. If an unaffected package has no p
 yet (e.g. a brand-new package), a full publish is performed instead. A change to the root
 `tsconfig.json` affects the compiled output of all packages and therefore also forces a full publish,
 as does a missing/invalid baseline or the `--full` flag. If no group is affected (e.g. docs- or CI-only
-changes), the command succeeds without publishing anything.
+changes), the command succeeds without publishing anything. Canary versions that already exist on the
+registry are skipped: the commit count only grows, so they can only stem from an earlier run over the
+same commit — this makes re-runs (e.g. to heal a partially failed publish) idempotent.
 
 `pnpm publish -r` does the publishing, so it rewrites `workspace:` dependency ranges to exact
 versions; npm provenance/trusted publishing (`NPM_CONFIG_PROVENANCE`) is preserved.