@eclipse-glsp/cli 2.9.0-next.1 → 2.9.0-next.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,9 +1,9 @@
1
1
  # Eclipse GLSP - CLI
2
2
 
3
3
  The `@eclipse-glsp/cli` package provides helpful scripts and commands for extension and application development.
4
- The contributed `glsp`, is a command line tool that offers all contributed commands.
4
+ It contributes `glsp`, a command line tool that offers all of these commands.
5
5
 
6
- ## Getting Started
6
+ ## Getting started
7
7
 
8
8
  Install `@eclipse-glsp/cli` as a dev dependency in your application.
9
9
 
@@ -31,10 +31,10 @@ Commands:
31
31
 
32
32
  ## checkHeaders
33
33
 
34
- The `checkHeaders` command can be used to validate the copyright year (range) of license headers.
34
+ The `checkHeaders` command validates the copyright year (range) of license headers.
35
35
  It checks for each file (matching the include pattern) whether the defined copyright range is in line with the first and last modification date in the git repository.
36
- Found violations are printed to the console and can be fixed automatically.
37
- The validation check can be restricted to pending changes and/or the last commit e.g. to validate a commit before creating a PR.
36
+ It prints the violations it finds to the console and can fix them automatically.
37
+ Restrict the check to pending changes or the last commit, for example to validate a commit before opening a PR.
38
38
 
39
39
  ```console
40
40
  $ glsp checkHeaders -h
@@ -78,7 +78,7 @@ Options:
78
78
 
79
79
  ## generateIndex
80
80
 
81
- Use this command to create an index file of all sources for a given directory and all it's sub directories.
81
+ Use this command to create an index file of all sources in a given directory and its sub-directories.
82
82
 
83
83
  ```console
84
84
  $ glsp generateIndex -h
@@ -131,8 +131,8 @@ Commands:
131
131
 
132
132
  Command to bump the version of all packages in a GLSP repository.
133
133
  This bumps the version of all workspace packages (the root `package.json` version is the source of truth).
134
- In addition, external GLSP dependencies are considered and bumped as well; `workspace:` ranges are preserved.
135
- The glsp repository type ("glsp-client", "glsp-server-node" etc.) is auto detected from the given repository path.
134
+ It also bumps external GLSP dependencies and preserves `workspace:` ranges.
135
+ The glsp repository type ("glsp-core", "glsp-theia-integration" etc.) is auto detected from the given repository path.
136
136
  If the command is invoked in a non-GLSP repository it will fail.
137
137
 
138
138
  ```console
@@ -155,10 +155,10 @@ Options:
155
155
  ### prepare
156
156
 
157
157
  Prepares a new release for a GLSP repository.
158
- This includes bumping the version, updating the changelog, commit & push the changes
158
+ This includes bumping the version, updating the changelog, committing and pushing the changes
159
159
  and opening a PR for the release.
160
160
 
161
- The glsp repository type ("glsp-client", "glsp-server-node" etc.) is auto detected from the given repository path.
161
+ The glsp repository type ("glsp-core", "glsp-theia-integration" etc.) is auto detected from the given repository path.
162
162
  If the command is invoked in a non-GLSP repository it will fail.
163
163
 
164
164
  ```console
@@ -183,22 +183,42 @@ Options:
183
183
 
184
184
  ### publish
185
185
 
186
- Publishes all (public) workspace packages of a GLSP repository via `pnpm publish -r` (replaces `lerna publish`).
186
+ Publishes the (public) workspace packages of a GLSP repository via `pnpm publish -r` (replaces `lerna publish`).
187
187
 
188
- - `next`: applies a canary version (`<root-version>.<commits-since-last-tag>`, e.g. `2.8.0-next.42`) to all
189
- workspace packages and publishes them under the `next` dist-tag. Requires the full git history
190
- (`fetch-depth: 0` in CI) to derive the commit count.
188
+ - `next`: applies a canary version (`<root-version>.<commit-count>`, e.g. `2.8.0-next.42`, counted since the
189
+ last release tag `v*` or from the root commit if none exists) and publishes under the `next` dist-tag.
190
+ Requires the full git history (`fetch-depth: 0` in CI) to derive the commit count.
191
191
  - `latest`: publishes the current package versions under the `latest` dist-tag. Packages whose version
192
192
  already exists on the registry are skipped.
193
193
 
194
- Publishing is delegated to `pnpm publish -r`, so `workspace:` dependency ranges are rewritten to exact
194
+ `next` publishing is _affected-only_ per package. Changes are detected from the last commit
195
+ (`HEAD^..HEAD`, matching the previous per-repo publish workflows; override the baseline with
196
+ `--since <ref>`). A package is published when files in its directory changed, or when a package it
197
+ (transitively) depends on via a `workspace:` range is published (e.g. a `protocol` change also
198
+ publishes `sprotty`, `client`, `server` and the examples, so the newest nightlies always form a
199
+ consistent set — while a `client`-only change publishes just `client` and its dependents).
200
+
201
+ Published packages carry exact-pinned internal dependencies: packages in the affected groups get the
202
+ canary version, while packages outside them are locally pinned to their currently published `next`
203
+ version (resolved via `npm view`), so every `workspace:` pin of a published package resolves to a
204
+ version that exists on npm. Because a dependency change always republishes all dependents, the pinned
205
+ version is the same one the other nightlies already reference — the newest nightly of every package
206
+ always forms one consistent, reproducible set. If an unaffected package has no published `next` version
207
+ yet (e.g. a brand-new package), a full publish is performed instead. A change to the root
208
+ `tsconfig.json` affects the compiled output of all packages and therefore also forces a full publish,
209
+ as does a missing/invalid baseline or the `--full` flag. If no group is affected (e.g. docs- or CI-only
210
+ changes), the command succeeds without publishing anything. Canary versions that already exist on the
211
+ registry are skipped: the commit count only grows, so they can only stem from an earlier run over the
212
+ same commit — this makes re-runs (e.g. to heal a partially failed publish) idempotent.
213
+
214
+ `pnpm publish -r` does the publishing, so it rewrites `workspace:` dependency ranges to exact
195
215
  versions; npm provenance/trusted publishing (`NPM_CONFIG_PROVENANCE`) is preserved.
196
216
 
197
217
  ```console
198
218
  $ glsp releng publish -h
199
219
  Usage: glsp releng publish [options] <distTag>
200
220
 
201
- Publish all workspace packages of a GLSP repository via `pnpm publish`
221
+ Publish the affected workspace packages of a GLSP repository via `pnpm publish`
202
222
 
203
223
  Arguments:
204
224
  distTag The npm dist-tag to publish under (choices: "next", "latest")
@@ -208,16 +228,18 @@ Options:
208
228
  -r, --repoDir <repoDir> Path to the component repository (default: "<cwd>")
209
229
  --dry-run Derive versions and run `pnpm publish` in dry-run mode without applying changes (default: false)
210
230
  --registry <url> Publish to a custom npm registry (e.g. a local verdaccio for testing)
231
+ --since <ref> Baseline for affected-only 'next' publishing (default: HEAD^, i.e. the changes of the last commit)
232
+ --full Publish all packages, ignoring the affected-only baseline ('next' only) (default: false)
211
233
  -h, --help display help for command
212
234
  ```
213
235
 
214
236
  ## repo
215
237
 
216
238
  Multi-repository workspace management for GLSP development.
217
- All repositories are expected to live as siblings in a shared workspace directory (e.g. `~/glsp/glsp-client`, `~/glsp/glsp-server-node`, etc.).
218
- Repositories are auto-discovered by scanning the workspace directory for known GLSP repo names.
219
- The workspace directory is resolved automatically by walking up from the current directory; it can be overridden with `--dir`.
220
- The clone protocol is auto-detected: if the GitHub CLI (`gh`) is installed and authenticated, `gh` is used; otherwise `https`.
239
+ All repositories are expected to live as siblings in a shared workspace directory (e.g. `~/glsp/glsp-core`, `~/glsp/glsp-theia-integration`, etc.).
240
+ The CLI discovers repositories by scanning the workspace directory for known GLSP repo names.
241
+ It finds the workspace directory by walking up from the current directory. Override it with `--dir`.
242
+ The clone protocol is detected automatically. If the GitHub CLI (`gh`) is installed and authenticated, the CLI uses `gh`, otherwise `https`.
221
243
  This can be overridden per command via `--protocol`.
222
244
 
223
245
  ```bash
@@ -238,14 +260,11 @@ Commands:
238
260
  pwd [options] Print resolved paths for all discovered repositories
239
261
  log [options] Print the last commit for all discovered repositories
240
262
  workspace Manage VS Code workspace files for GLSP projects
241
- glsp Operations on the glsp repository
242
- glsp-server-node|server-node Operations on the glsp-server-node repository
243
- glsp-client|client Operations on the glsp-client repository
263
+ glsp-core|core Operations on the glsp-core repository
244
264
  glsp-theia-integration|theia Operations on the glsp-theia-integration repository
245
265
  glsp-vscode-integration|vscode Operations on the glsp-vscode-integration repository
246
266
  glsp-eclipse-integration|eclipse Operations on the glsp-eclipse-integration repository
247
267
  glsp-server|server-java Operations on the glsp-server repository
248
- glsp-playwright|playwright Operations on the glsp-playwright repository
249
268
  help [command] display help for command
250
269
  ```
251
270
 
@@ -328,8 +347,8 @@ Options:
328
347
 
329
348
  Links (or unlinks) repositories for cross-repo development by injecting `link:` overrides into each
330
349
  consumer's `pnpm-workspace.yaml` and reinstalling. Repositories are processed in dependency order, and
331
- singleton dependencies (sprotty, sprotty-protocol, vscode-jsonrpc, inversify) are shared from `glsp-client`
332
- to avoid duplicate instances. After linking a repo it is **built** so the `link:` overrides resolve to
350
+ singleton dependencies (sprotty, sprotty-protocol, vscode-jsonrpc, inversify) are shared from `glsp-core`
351
+ to avoid duplicate instances. After linking a repo the CLI builds it, so the `link:` overrides resolve to
333
352
  compiled `lib/` output rather than empty source directories (pass `--no-build` to skip); only the npm/pnpm
334
353
  side is built, so the `glsp-eclipse-integration` Maven server is left to a separate build. `unlink` removes
335
354
  those overrides again and reinstalls.
@@ -422,35 +441,53 @@ Options:
422
441
  ### Scoped repository commands
423
442
 
424
443
  Each repository has a set of scoped subcommands accessible via `glsp repo <name>` or its short alias.
425
- Short aliases: `client`, `server-node`, `theia`, `vscode`, `eclipse`, `server-java`, `playwright`.
444
+ Short aliases: `core`, `theia`, `vscode`, `eclipse`, `server-java`.
426
445
 
427
446
  All repos support `clone`, `switch`, `build`, `pwd`, and `log` subcommands.
428
447
  Some repos have additional repo-specific commands:
429
448
 
430
449
  | Repo | Extra commands |
431
450
  | ------------------------- | ---------------------- |
432
- | `glsp-client` | `start` |
433
- | `glsp-server-node` | `start` |
451
+ | `glsp-core` | `client`, `server` |
434
452
  | `glsp-server` | `start` |
435
453
  | `glsp-theia-integration` | `start`, `open` |
436
454
  | `glsp-vscode-integration` | `vsix-path`, `package` |
437
455
 
456
+ `glsp-core` bundles several components in one repository, so it groups them instead of offering a single `start`.
457
+ `glsp repo core client start` runs the standalone example, `glsp repo core server start` the node GLSP
458
+ server, and `glsp repo core server node-bundle` / `browser-bundle` print the built server bundle paths.
459
+
438
460
  ```console
439
- $ glsp repo client -h
440
- Usage: glsp repo glsp-client|client [options] [command]
461
+ $ glsp repo core -h
462
+ Usage: glsp repo glsp-core|core [options] [command]
441
463
 
442
- Operations on the glsp-client repository
464
+ Operations on the glsp-core repository
443
465
 
444
466
  Commands:
445
- clone [options] Clone the glsp-client repository
446
- switch [options] Switch branch or checkout a PR in glsp-client
447
- build [options] Build the glsp-client repository
448
- pwd [options] Print the resolved path for glsp-client
449
- log [options] Print the last commit for glsp-client
450
- start [options] Start the standalone example for glsp-client
467
+ clone [options] Clone the glsp-core repository
468
+ switch [options] Switch branch or checkout a PR in glsp-core
469
+ build [options] Build the glsp-core repository
470
+ pwd [options] Print the resolved path for glsp-core
471
+ log [options] Print the last commit for glsp-core
472
+ run [options] Run an arbitrary package.json script in glsp-core
473
+ client Operations on the GLSP client and its standalone example
474
+ server Operations on the node GLSP server and its workflow example
451
475
  help [command] display help for command
452
476
  ```
453
477
 
478
+ ```console
479
+ $ glsp repo core server -h
480
+ Usage: glsp repo glsp-core|core server [options] [command]
481
+
482
+ Operations on the node GLSP server and its workflow example
483
+
484
+ Commands:
485
+ start [options] Start the workflow example node GLSP server
486
+ node-bundle [options] Print the absolute path to the Node.js server bundle
487
+ browser-bundle [options] Print the absolute path to the browser (Web Worker) server bundle
488
+ help [command] display help for command
489
+ ```
490
+
454
491
  ```console
455
492
  $ glsp repo vscode -h
456
493
  Usage: glsp repo glsp-vscode-integration|vscode [options] [command]