@jskit-ai/agent-docs 0.1.83 → 0.1.84
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.
|
@@ -106,6 +106,25 @@ npm run release -- --registry https://registry.example.com
|
|
|
106
106
|
|
|
107
107
|
When the app declares npm workspaces, the command asks npm for the workspace graph and aligns JSKIT references in each workspace `package.json` and `package.descriptor.mjs` to the latest major range, such as `0.x`. Descriptor dependency mutations are included whether they use a direct string or a conditional `{ version, when }` record. It then runs `npm update --workspaces` for those packages so `package-lock.json` reflects the aligned ranges. Non-JSKIT dependencies and the public descriptor format are left alone.
|
|
108
108
|
|
|
109
|
+
Updating npm packages is only half of a JSKIT upgrade. Package descriptors also own managed files, source and text mutations, lock metadata, migrations, and CI contributions. After installing newer root packages, `update-packages` compares their target versions with the installed records in `.jskit/lock.json`. It reapplies each changed installed package through the same `jskit update package ...` lifecycle used for a manual update. The newly installed local CLI performs that work, saved package options are reused, and customized app-owned files remain protected by the normal ownership checks. The updater reloads the lock between packages, so a dependency already upgraded while reapplying another package is not applied twice.
|
|
110
|
+
|
|
111
|
+
This means the normal existing-app upgrade is one command:
|
|
112
|
+
|
|
113
|
+
```bash
|
|
114
|
+
npm run jskit:update
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
After it succeeds, npm dependencies and descriptor-managed app state are current together. If a managed app-owned file is missing, a required saved option can no longer be resolved, or another package update cannot be applied safely, the app-wide update fails instead of leaving that package silently stale. `--dry-run` reports which installed packages would be reapplied without invoking their update lifecycle.
|
|
118
|
+
|
|
119
|
+
There is one unavoidable bootstrap detail for apps whose installed CLI predates managed package reapplication: a CLI process that is already running cannot adopt code npm installs underneath it. Upgrade the CLI once, then run the app-wide update with the new process:
|
|
120
|
+
|
|
121
|
+
```bash
|
|
122
|
+
npm install --save-dev --save-exact @jskit-ai/jskit-cli@latest
|
|
123
|
+
npm run jskit:update
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
After that bootstrap, normal future upgrades use only `npm run jskit:update`. Do not work around the first upgrade by editing `.jskit/lock.json`; the new updater must reapply the descriptor contract and write managed state itself.
|
|
127
|
+
|
|
109
128
|
The update reports elapsed progress for registry and install work. It also refreshes JSKIT-managed migrations and CI after root package changes. Preview the complete operation without changing manifests, descriptors, the lockfile, migrations, or CI with:
|
|
110
129
|
|
|
111
130
|
```bash
|
|
@@ -781,7 +800,7 @@ Good times to run it manually include:
|
|
|
781
800
|
- when a package appears installed in the lock but starts behaving as if it is missing
|
|
782
801
|
- when you want a fast JSKIT-specific health check without waiting for a full test suite
|
|
783
802
|
|
|
784
|
-
One important nuance: `doctor` is checking for broken JSKIT ownership and visibility, not trying to stop you from editing app-owned files. For example, a managed file that still exists but whose contents changed is normally fine.
|
|
803
|
+
One important nuance: `doctor` is checking for broken JSKIT ownership and visibility, not trying to stop you from editing app-owned files. For example, a managed file that still exists but whose contents changed is normally fine. An app-owned file explicitly installed by a package can also live under `packages/main/src/server/` without being mistaken for undeclared domain logic. The file remains part of managed state, so deleting it is still an error. Unrelated server files under `packages/main` continue to receive the normal feature-lane warning.
|
|
785
804
|
|
|
786
805
|
There is one intentional exception for user-facing UI work.
|
|
787
806
|
|
package/package.json
CHANGED
|
@@ -572,7 +572,9 @@ Exports
|
|
|
572
572
|
|
|
573
573
|
### `src/server/commandHandlers/appCommands/updatePackages.js`
|
|
574
574
|
Exports
|
|
575
|
+
- `collectChangedInstalledPackageIds(lock = {}, latestVersions = new Map())`
|
|
575
576
|
- `formatElapsedTime(elapsedMilliseconds = 0)`
|
|
577
|
+
- `reapplyChangedInstalledPackages({ appRoot, createCliError, dryRun, latestVersions, loadLockFile, stderr, stdout })`
|
|
576
578
|
- `runAppUpdatePackagesCommand(ctx = {}, { appRoot = "", options = {}, stdout, stderr })`
|
|
577
579
|
- `runWithProgress(task, { activity, progressIntervalMs = PROGRESS_INTERVAL_MS, stdout, step } = {})`
|
|
578
580
|
Local functions
|