Sync the wrapper with @ua/cordova-airship 19.1.0: Live Activity manager
(iOS), Live Update manager (Android), contact email/SMS registration,
JSON attribute editing, push enableUserNotifications, iOS badge reset,
and new Feature enum values.
Angular 21 needs typescript >=5.9 <6.1; the pinned ~5.9.3 already satisfies
it, and the node engine range is unchanged from 20.
Verified against the published 9.3.0 artifacts (built with Angular 20.3.18):
the emitted .d.ts files are byte-identical and the only diff in the emitted
JS is the partial-compilation metadata string, version "20.3.18" -> "21.2.18".
minVersion stays "12.0.0", so the Angular linker floor for consumers does not
move — the library only uses @Injectable, whose declaration format has been
stable since Angular 12.
Raises the renovate cap accordingly. Angular 22 stays out: it requires
typescript >=6.0 <6.1, which turns the `module: ES2022` + `moduleResolution:
Node16` pair in scripts/build/ngx.ts into a hard TS5110 error.
@angular/compiler-cli pinned @babel/core 7.29.0, which is affected by
GHSA-4x5r-pxfx-6jf8 (arbitrary file read via sourceMappingURL). 20.3.26 pins
7.29.7. Staying inside Angular 20 keeps the emitted partial-compilation
declarations unchanged (minVersion 12.0.0), so nothing changes for consumers.
npm audit fix additionally resolved the transitive brace-expansion
GHSA-3jxr-9vmj-r5cp in the lockfile.
enabledManagers was limited to npm, so action versions never got update PRs
and drifted up to three majors behind — checkout and setup-node were still on
v4 while v7 was current.
The existing packageRules all match on `matchManagers: ["npm"]`, so action
updates fall through to the defaults: individual PRs, no automerge, reviewed
like any other major.
The only breaking change in v5.0.0 is the move to the node 24 runtime; inputs,
outputs and the manifest/config format are unchanged. Kept as its own commit
since this action drives the release flow and is the one worth reverting alone
if anything misbehaves.
checkout v4.3.1 -> v7.0.1, setup-node v4.4.0 -> v7.0.0, stale v9.1.0 -> v10.4.0.
The breaking changes across those majors do not apply here:
- checkout v5/v6 harden `pull_request_target` checkouts; no workflow uses it
- setup-node v5 auto-caches when package.json has a `packageManager` field;
it has none, and `cache: npm` is set explicitly anyway
- setup-node v7 drops the dummy NODE_AUTH_TOKEN export; the publish job sets
NODE_AUTH_TOKEN itself
- stale v10 only moves the runtime to node 24
All of them also raise the runtime to node 24, which clears the deprecation
warnings on recent runs.
Also drops the explicit `npm install -g npm@latest` step: node 24 bundles
npm 11.16, well over the >= 11.5.1 that trusted publishing requires. Pulling
an unpinned npm@latest right before publishing 258 packages was the larger
risk of the two.
npm validates the OIDC claim of the entry-point workflow, not the one that
runs `npm publish`. Calling publish.yml via workflow_call meant the trust
check could never match, so the publish job moves inline into
release-please.yml and publish.yml is removed.
setup-node with Node 22 ships npm 10.x; trusted publishing needs >= 11.5.1,
hence the explicit npm upgrade before publishing.
NPM_TOKEN stays as a fallback for packages that have no trusted publisher
yet — a brand new plugin cannot get one until it exists on npm. OIDC takes
precedence wherever a config is present.
Adds scripts/tasks/trust-packages.sh to configure the trusted publisher for
all 258 packages; npm has no multi-package call and `npm trust` requires
interactive 2FA, so it runs locally, in parallel, and is resumable.
Daniel Sogl
