@zenuml/core 3.46.3 → 3.46.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/.claude/skills/land-pr/SKILL.md +27 -5
- package/.claude/skills/ship-branch/SKILL.md +13 -0
- package/dist/stats.html +1 -1
- package/dist/zenuml.esm.mjs +3688 -3693
- package/dist/zenuml.js +69 -69
- package/package.json +1 -1
- package/docs/CONTEXT-tier2-component.md +0 -96
- package/docs/CONTEXT-tier3-feature.md +0 -162
- package/docs/README.md +0 -207
- package/docs/handling-starter.png +0 -0
- package/docs/module-vs-main-in-package-json.md +0 -17
- package/docs/open-issues/example-api-performance-issue.md +0 -79
- package/docs/osx-unsupported-arm64-node12.md +0 -13
- package/docs/running-cypress-tests-locally.md +0 -76
- package/docs/ship-branch-skill-plan.md +0 -134
- package/docs/superpowers/plans/2026-03-23-svg-parity-features.md +0 -283
- package/docs/testing-minified-lib.md +0 -27
- package/docs/watch.md +0 -1
- package/docs/why-we-publish-embed-view-to-github-pages.md +0 -16
|
@@ -28,17 +28,39 @@ If any precondition fails, report which one and stop. Do not attempt to fix —
|
|
|
28
28
|
|
|
29
29
|
Run the precondition checks above. If anything is not green, stop and report.
|
|
30
30
|
|
|
31
|
-
### 2.
|
|
31
|
+
### 2. Decide merge strategy
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
Inspect the branch's commit history to decide between squash and merge:
|
|
34
34
|
|
|
35
35
|
```bash
|
|
36
|
+
git log main..HEAD --oneline
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
**Auto-squash if ANY of these are true:**
|
|
40
|
+
- Only 1 commit on the branch
|
|
41
|
+
- Commit messages contain noise patterns: "wip", "fixup", "temp", "oops", "try again", "fix lint", "fix test", duplicate messages
|
|
42
|
+
- More than half the commits have the same or very similar messages
|
|
43
|
+
|
|
44
|
+
**Merge (preserve commits) if ALL of these are true:**
|
|
45
|
+
- 2+ commits with distinct, meaningful messages
|
|
46
|
+
- Each commit describes a self-contained step (not just iterations on the same change)
|
|
47
|
+
- Commits follow a logical progression (e.g., "add X" → "refactor Y" → "delete Z")
|
|
48
|
+
|
|
49
|
+
Announce the decision and why: "Squashing — 3 of 5 commits are fixups" or "Merging — 8 clean commits with distinct steps".
|
|
50
|
+
|
|
51
|
+
### 3. Execute merge
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
# If squash:
|
|
36
55
|
gh pr merge <PR_NUMBER> --squash --auto
|
|
56
|
+
|
|
57
|
+
# If merge:
|
|
58
|
+
gh pr merge <PR_NUMBER> --merge --auto
|
|
37
59
|
```
|
|
38
60
|
|
|
39
61
|
Using `--auto` arms auto-merge so GitHub merges when all checks pass. If checks are already green, it merges immediately.
|
|
40
62
|
|
|
41
|
-
###
|
|
63
|
+
### 4. Wait for merge
|
|
42
64
|
|
|
43
65
|
If auto-merge was armed, wait for it:
|
|
44
66
|
|
|
@@ -48,7 +70,7 @@ gh pr view <PR_NUMBER> --json state
|
|
|
48
70
|
|
|
49
71
|
Poll until state is `MERGED`. Timeout after 5 minutes — if not merged by then, report and stop.
|
|
50
72
|
|
|
51
|
-
###
|
|
73
|
+
### 5. Monitor npm publish
|
|
52
74
|
|
|
53
75
|
After merge, the `Build, Test, npm Publish, and Deploy` workflow runs on `main`. Watch it:
|
|
54
76
|
|
|
@@ -62,7 +84,7 @@ Wait for the run to complete:
|
|
|
62
84
|
gh run watch <RUN_ID> --repo mermaid-js/zenuml-core
|
|
63
85
|
```
|
|
64
86
|
|
|
65
|
-
###
|
|
87
|
+
### 6. Verify npm publish
|
|
66
88
|
|
|
67
89
|
Check that the new version appeared on npm:
|
|
68
90
|
|
|
@@ -10,6 +10,8 @@ Orchestrate the full path from local branch to npm release. This skill composes
|
|
|
10
10
|
## Flow
|
|
11
11
|
|
|
12
12
|
```
|
|
13
|
+
rebase on origin/main → CONFLICT → stop, report
|
|
14
|
+
| CLEAN
|
|
13
15
|
validate-branch → FAIL → stop, report
|
|
14
16
|
| PASS
|
|
15
17
|
submit-branch → FAIL → stop, report
|
|
@@ -25,6 +27,17 @@ land-pr → PUBLISH FAIL → alert, stop
|
|
|
25
27
|
|
|
26
28
|
## Steps
|
|
27
29
|
|
|
30
|
+
### Step 0: Rebase on remote main
|
|
31
|
+
|
|
32
|
+
Fetch and rebase onto `origin/main` to ensure the branch is up to date before validating.
|
|
33
|
+
|
|
34
|
+
```bash
|
|
35
|
+
git fetch origin main
|
|
36
|
+
git rebase origin/main
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
If the rebase has conflicts, stop immediately and report. The developer must resolve conflicts manually before shipping.
|
|
40
|
+
|
|
28
41
|
### Step 1: Validate locally
|
|
29
42
|
|
|
30
43
|
Invoke `/validate-branch`. If it reports FAIL, stop and show the failure. The developer needs to fix locally before shipping.
|