@draekien/create-d9-app 0.0.3 → 0.0.5
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/package.json
CHANGED
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: upgrade-dependencies
|
|
3
|
+
description: Upgrades outdated patch and minor dependency pins in a pnpm, npm, yarn or bun workspace to exact versions, holds major upgrades until the developer confirms each one, runs build, check, typecheck and test, and reports every change. Applies when asked to "upgrade dependencies", "update packages", "bump versions", "update deps", or "confirm major upgrades".
|
|
4
|
+
argument-hint: "[--accept]"
|
|
5
|
+
allowed-tools: Bash(npm view *), Bash(gh release view *), Bash(gh api *), Bash(pnpm *), Bash(npm *), Bash(yarn *), Bash(bun *), Bash(git diff *), Bash(git status *)
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Upgrade dependencies
|
|
9
|
+
|
|
10
|
+
Arguments: `$ARGUMENTS`. `--accept` means the developer accepts the patch and minor breaking-change list in advance; proceed at step 4 without stopping. `--accept` never confirms a major.
|
|
11
|
+
|
|
12
|
+
Apply patch and minor upgrades without per-package confirmation. Apply a major only after the developer confirms that package in step 7.
|
|
13
|
+
|
|
14
|
+
## 1. Read the workspace
|
|
15
|
+
|
|
16
|
+
- Package manager: root `package.json` field `packageManager` (`pnpm@11.25.0` means `pnpm`). Call it `<pm>` below.
|
|
17
|
+
- Manifests: root `package.json`, `apps/*/package.json`, `packages/*/package.json`.
|
|
18
|
+
- Pins: entries in `dependencies`, `devDependencies`, `optionalDependencies`. Skip `workspace:*`, `link:`, `file:`, `git`, `npm:` alias and URL specs.
|
|
19
|
+
- Minimum age in minutes: `minimumReleaseAge` in `pnpm-workspace.yaml` or `.npmrc`; if unset, `1440`.
|
|
20
|
+
|
|
21
|
+
## 2. Find upgrades
|
|
22
|
+
|
|
23
|
+
Run once per distinct package name:
|
|
24
|
+
|
|
25
|
+
```sh
|
|
26
|
+
npm view <pkg> versions time --json
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
```json
|
|
30
|
+
{
|
|
31
|
+
"versions": ["5.9.2", "5.9.3", "6.0.0-beta", "6.0.2", "6.0.3"],
|
|
32
|
+
"time": {
|
|
33
|
+
"created": "2012-10-01T15:35:39.553Z",
|
|
34
|
+
"modified": "2026-10-10T08:24:07.208Z",
|
|
35
|
+
"5.9.3": "2025-09-30T21:19:38.784Z",
|
|
36
|
+
"6.0.0-beta": "2026-02-11T18:26:37.557Z",
|
|
37
|
+
"6.0.2": "2026-03-23T16:14:45.521Z",
|
|
38
|
+
"6.0.3": "2026-04-16T23:38:27.905Z"
|
|
39
|
+
}
|
|
40
|
+
}
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
A package with one version returns `versions` as a string, not an array.
|
|
44
|
+
|
|
45
|
+
Candidates: versions without a `-` prerelease suffix, with `time[version]` at least the minimum age before now.
|
|
46
|
+
|
|
47
|
+
- Same major as the pin, newer than the pin: take the highest. Type is `minor` if the minor differs, else `patch`.
|
|
48
|
+
- Higher major exists: record the highest eligible version as a pending major. Do not apply it before step 7.
|
|
49
|
+
- No candidate newer than the pin: current.
|
|
50
|
+
- A 0.x pin is compared by its first non-zero segment: 0.13 to 0.14 is a major, 0.13.0 to 0.13.1 is a patch.
|
|
51
|
+
|
|
52
|
+
A pin is current when it has no eligible patch or minor. If no pin has an eligible patch or minor, change no files and skip to step 7. If no major is pending either, report `all pins current` and stop.
|
|
53
|
+
|
|
54
|
+
## 3. Read release notes
|
|
55
|
+
|
|
56
|
+
For each package to upgrade, read the notes for every release after the old version up to and including the new one.
|
|
57
|
+
|
|
58
|
+
```sh
|
|
59
|
+
gh release view v<version> --repo <owner>/<repo> --json body
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
- Repository: `npm view <pkg> repository.url`.
|
|
63
|
+
- No GitHub release for the tag: read `CHANGELOG.md` in the repository for the same range.
|
|
64
|
+
- Record each breaking change, deprecation and migration step per package.
|
|
65
|
+
|
|
66
|
+
## 4. Surface and stop
|
|
67
|
+
|
|
68
|
+
Print one list of patch and minor upgrades: package, old version, new version, type, breaking changes and migrations (or `none found`). Then:
|
|
69
|
+
|
|
70
|
+
- Without `--accept`: stop and ask the developer to accept or exclude packages. Edit nothing before the answer.
|
|
71
|
+
- With `--accept`: continue.
|
|
72
|
+
|
|
73
|
+
## 5. Apply
|
|
74
|
+
|
|
75
|
+
- Set each upgraded pin to the exact new version: no `^`, no `~`, no `latest`.
|
|
76
|
+
- Run `<pm> install`.
|
|
77
|
+
- Run each project script with `<pm> run <script>` in this order: `build`, `check`, `typecheck`, `test`. Skip a script the root `package.json` does not define.
|
|
78
|
+
|
|
79
|
+
## 6. Handle a failing check
|
|
80
|
+
|
|
81
|
+
For each failure:
|
|
82
|
+
|
|
83
|
+
- The release notes read in step 3 name the change and its migration: apply the migration, then re-run `<pm> install` and all four scripts.
|
|
84
|
+
- Otherwise: set the package that caused the failure back to its old version, re-run `<pm> install` and all four scripts. Report it as `held: check failed` with the error text.
|
|
85
|
+
|
|
86
|
+
Repeat until `build`, `check`, `typecheck` and `test` all exit 0. Never finish with a failing check.
|
|
87
|
+
|
|
88
|
+
## 7. Confirm and apply majors
|
|
89
|
+
|
|
90
|
+
After the patch and minor list, print each pending major as its own entry: package, current version, newest eligible major, and a summary of the release notes for the range current to new, read as in step 3, with breaking changes and migration steps called out.
|
|
91
|
+
|
|
92
|
+
- Ask the developer to confirm each major individually. Edit nothing before the answer. A major that is declined or not answered is held as `declined` or `not confirmed`.
|
|
93
|
+
- Apply confirmed majors one at a time: set the exact pin, run `<pm> install`, run the four scripts, and handle a failure as in step 6. A reverted major is `held: check failed`.
|
|
94
|
+
|
|
95
|
+
## 8. Report
|
|
96
|
+
|
|
97
|
+
Print a table of changed packages, including applied majors:
|
|
98
|
+
|
|
99
|
+
| Package | Old | New | Type |
|
|
100
|
+
| --- | --- | --- | --- |
|
|
101
|
+
| typescript | 5.9.2 | 5.9.3 | patch |
|
|
102
|
+
| vite | 7.1.0 | 8.0.0 | major |
|
|
103
|
+
|
|
104
|
+
Below it list:
|
|
105
|
+
|
|
106
|
+
- `held: major`: package, current version, newest eligible major, reason `declined` or `not confirmed`. List it even when every other pin is current; the no-change report is `all pins current` plus this list.
|
|
107
|
+
- `held: check failed`: package, old version, attempted version, error text. For a major, the reason is `check failed` with the error text.
|
|
108
|
+
- Migrations applied, with the file changed.
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: upgrade-dependencies
|
|
3
|
+
description: Upgrades outdated patch and minor dependency pins in a pnpm, npm, yarn or bun workspace to exact versions, holds major upgrades until the developer confirms each one, runs build, check, typecheck and test, and reports every change. Applies when asked to "upgrade dependencies", "update packages", "bump versions", "update deps", or "confirm major upgrades".
|
|
4
|
+
argument-hint: "[--accept]"
|
|
5
|
+
allowed-tools: Bash(npm view *), Bash(gh release view *), Bash(gh api *), Bash(pnpm *), Bash(npm *), Bash(yarn *), Bash(bun *), Bash(git diff *), Bash(git status *)
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Upgrade dependencies
|
|
9
|
+
|
|
10
|
+
Arguments: `$ARGUMENTS`. `--accept` means the developer accepts the patch and minor breaking-change list in advance; proceed at step 4 without stopping. `--accept` never confirms a major.
|
|
11
|
+
|
|
12
|
+
Apply patch and minor upgrades without per-package confirmation. Apply a major only after the developer confirms that package in step 7.
|
|
13
|
+
|
|
14
|
+
## 1. Read the workspace
|
|
15
|
+
|
|
16
|
+
- Package manager: root `package.json` field `packageManager` (`pnpm@11.25.0` means `pnpm`). Call it `<pm>` below.
|
|
17
|
+
- Manifests: root `package.json`, `apps/*/package.json`, `packages/*/package.json`.
|
|
18
|
+
- Pins: entries in `dependencies`, `devDependencies`, `optionalDependencies`. Skip `workspace:*`, `link:`, `file:`, `git`, `npm:` alias and URL specs.
|
|
19
|
+
- Minimum age in minutes: `minimumReleaseAge` in `pnpm-workspace.yaml` or `.npmrc`; if unset, `1440`.
|
|
20
|
+
|
|
21
|
+
## 2. Find upgrades
|
|
22
|
+
|
|
23
|
+
Run once per distinct package name:
|
|
24
|
+
|
|
25
|
+
```sh
|
|
26
|
+
npm view <pkg> versions time --json
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
```json
|
|
30
|
+
{
|
|
31
|
+
"versions": ["5.9.2", "5.9.3", "6.0.0-beta", "6.0.2", "6.0.3"],
|
|
32
|
+
"time": {
|
|
33
|
+
"created": "2012-10-01T15:35:39.553Z",
|
|
34
|
+
"modified": "2026-10-10T08:24:07.208Z",
|
|
35
|
+
"5.9.3": "2025-09-30T21:19:38.784Z",
|
|
36
|
+
"6.0.0-beta": "2026-02-11T18:26:37.557Z",
|
|
37
|
+
"6.0.2": "2026-03-23T16:14:45.521Z",
|
|
38
|
+
"6.0.3": "2026-04-16T23:38:27.905Z"
|
|
39
|
+
}
|
|
40
|
+
}
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
A package with one version returns `versions` as a string, not an array.
|
|
44
|
+
|
|
45
|
+
Candidates: versions without a `-` prerelease suffix, with `time[version]` at least the minimum age before now.
|
|
46
|
+
|
|
47
|
+
- Same major as the pin, newer than the pin: take the highest. Type is `minor` if the minor differs, else `patch`.
|
|
48
|
+
- Higher major exists: record the highest eligible version as a pending major. Do not apply it before step 7.
|
|
49
|
+
- No candidate newer than the pin: current.
|
|
50
|
+
- A 0.x pin is compared by its first non-zero segment: 0.13 to 0.14 is a major, 0.13.0 to 0.13.1 is a patch.
|
|
51
|
+
|
|
52
|
+
A pin is current when it has no eligible patch or minor. If no pin has an eligible patch or minor, change no files and skip to step 7. If no major is pending either, report `all pins current` and stop.
|
|
53
|
+
|
|
54
|
+
## 3. Read release notes
|
|
55
|
+
|
|
56
|
+
For each package to upgrade, read the notes for every release after the old version up to and including the new one.
|
|
57
|
+
|
|
58
|
+
```sh
|
|
59
|
+
gh release view v<version> --repo <owner>/<repo> --json body
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
- Repository: `npm view <pkg> repository.url`.
|
|
63
|
+
- No GitHub release for the tag: read `CHANGELOG.md` in the repository for the same range.
|
|
64
|
+
- Record each breaking change, deprecation and migration step per package.
|
|
65
|
+
|
|
66
|
+
## 4. Surface and stop
|
|
67
|
+
|
|
68
|
+
Print one list of patch and minor upgrades: package, old version, new version, type, breaking changes and migrations (or `none found`). Then:
|
|
69
|
+
|
|
70
|
+
- Without `--accept`: stop and ask the developer to accept or exclude packages. Edit nothing before the answer.
|
|
71
|
+
- With `--accept`: continue.
|
|
72
|
+
|
|
73
|
+
## 5. Apply
|
|
74
|
+
|
|
75
|
+
- Set each upgraded pin to the exact new version: no `^`, no `~`, no `latest`.
|
|
76
|
+
- Run `<pm> install`.
|
|
77
|
+
- Run each project script with `<pm> run <script>` in this order: `build`, `check`, `typecheck`, `test`. Skip a script the root `package.json` does not define.
|
|
78
|
+
|
|
79
|
+
## 6. Handle a failing check
|
|
80
|
+
|
|
81
|
+
For each failure:
|
|
82
|
+
|
|
83
|
+
- The release notes read in step 3 name the change and its migration: apply the migration, then re-run `<pm> install` and all four scripts.
|
|
84
|
+
- Otherwise: set the package that caused the failure back to its old version, re-run `<pm> install` and all four scripts. Report it as `held: check failed` with the error text.
|
|
85
|
+
|
|
86
|
+
Repeat until `build`, `check`, `typecheck` and `test` all exit 0. Never finish with a failing check.
|
|
87
|
+
|
|
88
|
+
## 7. Confirm and apply majors
|
|
89
|
+
|
|
90
|
+
After the patch and minor list, print each pending major as its own entry: package, current version, newest eligible major, and a summary of the release notes for the range current to new, read as in step 3, with breaking changes and migration steps called out.
|
|
91
|
+
|
|
92
|
+
- Ask the developer to confirm each major individually. Edit nothing before the answer. A major that is declined or not answered is held as `declined` or `not confirmed`.
|
|
93
|
+
- Apply confirmed majors one at a time: set the exact pin, run `<pm> install`, run the four scripts, and handle a failure as in step 6. A reverted major is `held: check failed`.
|
|
94
|
+
|
|
95
|
+
## 8. Report
|
|
96
|
+
|
|
97
|
+
Print a table of changed packages, including applied majors:
|
|
98
|
+
|
|
99
|
+
| Package | Old | New | Type |
|
|
100
|
+
| --- | --- | --- | --- |
|
|
101
|
+
| typescript | 5.9.2 | 5.9.3 | patch |
|
|
102
|
+
| vite | 7.1.0 | 8.0.0 | major |
|
|
103
|
+
|
|
104
|
+
Below it list:
|
|
105
|
+
|
|
106
|
+
- `held: major`: package, current version, newest eligible major, reason `declined` or `not confirmed`. List it even when every other pin is current; the no-change report is `all pins current` plus this list.
|
|
107
|
+
- `held: check failed`: package, old version, attempted version, error text. For a major, the reason is `check failed` with the error text.
|
|
108
|
+
- Migrations applied, with the file changed.
|