@coolms/core-angular 2.0.0-alpha.3 → 2.0.0-alpha.4

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/CHANGELOG.md ADDED
@@ -0,0 +1,88 @@
1
+ # Changelog
2
+
3
+ All notable changes to `@coolms/core-angular` are recorded here.
4
+
5
+ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
6
+
7
+ This file starts at the version named below, which is what the registry
8
+ currently serves. Earlier alphas are deliberately not reconstructed: entries are written
9
+ in the same commit as the work they describe, and inventing the ones that
10
+ predate this file would be a worse record than not having them.
11
+
12
+ ## 2.0.0-alpha.4 - 2026-09-27
13
+
14
+ ### Changed
15
+
16
+ - `ElevationService`: an elevation whose `expiresAt` is already past is
17
+ reported as expired **when its state is read** -- `state()` and
18
+ `elevated()` are plain accessors that compare against the clock and demote
19
+ the stored state on the spot -- rather than when a timer fires. A timer only
20
+ reschedules the announcement; the read does the work, which is what a
21
+ suspended tab, a moved clock or a missed tick could never defeat. The
22
+ service also reconciles on `visibilitychange` and `focus`, coalesced to one
23
+ refresh per two seconds.
24
+
25
+ ### Added
26
+
27
+ - `ElevationService` and the rest of the elevation client in the public API:
28
+ `elevationInterceptor`, `BYPASS_ELEVATION`, `ELEVATION_REQUIRED_HEADER`,
29
+ `ELEVATION_PROMPT` and the three `ELEVATION_WARNING_*` reasons. 2.0.0-alpha.3
30
+ did not export them, so a package importing `ElevationService` from the
31
+ published build failed to compile (TS2305) -- the reason this release was cut.
32
+ Measured on the bundles: 30 runtime exports in alpha.3, 51 here, none removed.
33
+ - `console@1`, the administration host contract (the platform rule: hosts implement contracts, modules offer entries):
34
+ `ConsoleEntry` and the six lists a module contributes as data (`routes`,
35
+ `bindings`, `topbar`, `overlays`, `panels`, `states`, `providers`),
36
+ `consoleEntry()` for an entry file that exports one object and runs nothing,
37
+ `assembleConsole()` which refuses a range this contract does not meet and
38
+ every collision (a path, a binding name, a top-bar id, a port claimed by two
39
+ modules) by name, and the host side a theme calls: `consoleChildren()` (one
40
+ lazy child per mount, `canMatch` from the manifest), `provideConsole()` (the
41
+ store with the host's and the modules' states, the registry bindings as an
42
+ initializer, every provision), `ConsoleActivation` (what the backend's
43
+ `ui.modules` says is installed: the tiles, overlays and panels to render,
44
+ and the modules named but missing from the build), and `ConsolePanelHost`,
45
+ the port a dock panel talks back through. `ApiManifest.ui` mirrors the
46
+ backend's section. The mount's `canMatch` answers once `AppInitService`
47
+ signals ready: the router recognises a pasted module URL while the
48
+ initializer is still fetching the manifest, and a synchronous read there
49
+ sent every cold deep link to the dashboard.
50
+ - Declares `bugs` so a page imported from this package, and the catalogue,
51
+ know where a correction is filed. The registry filled the gap from GitHub when
52
+ the manifest was silent; the declared field is the one that holds on any
53
+ registry.
54
+
55
+ **`DocumentApiManifest` gained `spacesAvailableUrl` and `spaceEnablementUrl`.**
56
+ Optional, mirroring the backend manifest DTO. They let the Documents space
57
+ accordion offer an *Add space* control instead of only ever losing entries when
58
+ a site is not enabled for documents.
59
+
60
+ Both optional, so a client built against an older backend simply hides the
61
+ control rather than showing one that cannot work.
62
+
63
+ ### Fixed
64
+
65
+ - The README named a package that does not exist (`@coolms/admin-ui-angular`),
66
+ said the package installs no toolchain of its own (it does, from its lockfile,
67
+ outside the workspace), said it was built against Angular 19 (it is built with
68
+ 22 and peers on ^22), listed `@angular/cdk` as a peer (it is not one), and said
69
+ `latest` waits for a stable release (npm points it at the newest alpha).
70
+
71
+ ## 2.0.0-alpha.3 -- 2026-09-03
72
+
73
+ **A pre-release, carrying no compatibility promise.** Published under the
74
+ `alpha` dist-tag.
75
+
76
+ The client runtime the other CoolMS Angular packages sit on: session and token
77
+ refresh with a single-flight coordinator, the boot manifest and application
78
+ config state, theme and user preferences, the error handler, the HTTP
79
+ interceptors, and the wire types the CoolMS API emits.
80
+
81
+ It is the bottom of the layer graph -- it has no `@coolms` peers of its own, and
82
+ no runtime dependencies at all. Angular, NGXS and RxJS are peers.
83
+
84
+ ### Fixed
85
+
86
+ - The Status section told readers the package was not published to npm, which
87
+ it served from its own npm page. It now states what does not change when a
88
+ version is tagged.
package/README.md CHANGED
@@ -20,11 +20,10 @@ it is only useful against a CoolMS backend.
20
20
 
21
21
  ## Layering
22
22
 
23
- ```
24
- @coolms/core-angular -> @coolms/admin-ui-angular -> @coolms/<module>-ui-angular
25
- ```
26
-
27
- The naming rule: `-angular` is a library, `-ui-angular` ships components.
23
+ The bottom of the CoolMS Angular packages: it has no `@coolms` peers of its own.
24
+ The UI kit (`@coolms/ui-angular`) and the feature packages -- the editors, the
25
+ viewers and the rest of `@coolms/*-angular` -- build on it; nothing here depends
26
+ on them.
28
27
 
29
28
  The reason this is a package rather than application code is federation. The UI
30
29
  kit and every federated remote need the session, config, error handling and
@@ -47,20 +46,22 @@ npm run build
47
46
 
48
47
  Produces `dist/` — FESM 2022 bundles plus type definitions, compiled in Angular's
49
48
  *partial* mode so the consuming application's own compiler finishes the job. That
50
- is what keeps a package built against 19.x working as an application moves
51
- forward. `@angular/*`, `@ngxs/store` and `rxjs` stay external, as peers.
49
+ is what keeps a build made with one Angular 22 release working in an application
50
+ on a later one within the peer range. `@angular/*`, `@ngxs/store` and `rxjs` stay external, as peers.
52
51
 
53
- The build runs through the admin application's `ng-packagr`, because this package
54
- deliberately installs **no toolchain and no framework of its own**: its
55
- `node_modules` is a relative symlink to the admin's, so exactly one `@angular`
56
- tree is ever in play. A second copy would give two type identities for the same
57
- class while the package is consumed from source.
52
+ On its own -- a clone, or CI -- it installs its toolchain (`ng-packagr`, the
53
+ Angular compiler, TypeScript) from its committed lockfile, and that is how a
54
+ published build is made. Inside the CoolMS workspace its `node_modules` is instead
55
+ a relative symlink to the admin application's, so exactly one `@angular` tree is
56
+ in play while the admin consumes this package from source: a second copy would
57
+ give two type identities for the same class.
58
58
 
59
59
  ## Status
60
60
 
61
61
  A pre-release: the shape is still moving and it carries no compatibility
62
- promise. Published under the `alpha` dist-tag; `latest` will move to the first
63
- stable release when there is one.
62
+ promise. Published under the `alpha` dist-tag. Until a stable release exists, `latest`
63
+ points at the newest alpha as well -- npm set it on the first publish -- so a bare
64
+ `npm install @coolms/core-angular` gets a pre-release.
64
65
 
65
66
  The CoolMS admin application consumes it from source via a TypeScript path
66
67
  mapping rather than from the registry, so the published build and the one the
@@ -68,7 +69,7 @@ admin runs are produced the same way but resolved differently.
68
69
 
69
70
  ## Requirements
70
71
 
71
- Angular, NGXS, RxJS and `@angular/cdk` are peers; the supported ranges are declared in `package.json`, which is what an install actually checks.
72
+ Angular (`common`, `core`, `forms`, `router`), NGXS and RxJS are peers; the supported ranges are declared in `package.json`, which is what an install actually checks.
72
73
 
73
74
  ## Licence
74
75