@zenuml/core 3.46.8 → 3.46.10

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.
@@ -1,6 +1,6 @@
1
1
  # Downstream Repos
2
2
 
3
- Canonical downstream targets for propagating a published `@zenuml/core` release.
3
+ Canonical downstream targets for filing rollout issues after a published `@zenuml/core` release.
4
4
 
5
5
  ## Repo Table
6
6
 
@@ -14,29 +14,29 @@ Canonical downstream targets for propagating a published `@zenuml/core` release.
14
14
  | `ZenUml/codemirror-extensions` | `~/workspaces/zenuml/codemirror-extensions` | pnpm | `pnpm update @zenuml/core` | `pnpm build` | CodeMirror language extensions for ZenUML DSL. HTML-renderer consumer. |
15
15
  | `ZenUml/jetbrains-zenuml` | `~/workspaces/zenuml/jetbrains-zenuml` | — | See notes | — | **Not an npm consumer.** Vendors a built JS bundle. Update by copying the new `dist/` output from core's build. Skip if unsure and report. |
16
16
 
17
- ## Lockfile Handling
17
+ ## Issue Authoring Guidance
18
18
 
19
- After every dependency update, regenerate the lockfile:
19
+ When writing a downstream issue for an npm consumer, explicitly include the lockfile refresh step:
20
20
 
21
21
  - **pnpm**: `pnpm install` (updates `pnpm-lock.yaml`)
22
22
  - **yarn**: `yarn install` (updates `yarn.lock`)
23
23
 
24
- Always commit the lockfile alongside the `package.json` change. A PR without an updated lockfile will fail CI.
24
+ Tell the downstream team to include the updated lockfile in the PR. A PR without an updated lockfile will usually fail CI.
25
25
 
26
- ## Clone Strategy
26
+ ## Local Checkout Usage
27
27
 
28
- If a local path does not exist:
28
+ Local checkouts are optional for this skill. Use them only if you need extra context to clarify the issue body safely. Do not clone repos just to file the issue.
29
+
30
+ If you do need a checkout and the local path does not exist:
29
31
 
30
32
  ```bash
31
33
  gh repo clone <repo-slug> <local-path>
32
34
  ```
33
35
 
34
- Then proceed with fetch + branch creation as usual.
35
-
36
36
  ## General Rules
37
37
 
38
- - Each repo gets its own update branch and its own draft PR.
39
- - Reuse existing propagation branches or draft PRs when they already target the same core version.
38
+ - Each repo gets its own rollout issue.
39
+ - Reuse an existing open issue when it already targets the same core version.
40
40
  - `mermaid-js/mermaid` and `mermaid-js/mermaid-live-editor` are under the `mermaid-js` GitHub org (not `ZenUml`).
41
41
  - Only `mermaid-js/mermaid` and `mermaid-js/mermaid-live-editor` should receive SVG-renderer integration changes tied to core API/export changes.
42
42
  - Treat all other downstreams as HTML-renderer consumers unless the user explicitly asks for a renderer migration.
@@ -0,0 +1,17 @@
1
+ {
2
+ "mcpServers": {
3
+ "playwright": {
4
+ "command": "npx",
5
+ "args": ["@playwright/mcp@latest", "--extension"],
6
+ "env": {
7
+ "PLAYWRIGHT_MCP_EXTENSION_TOKEN": "<your-token-here>"
8
+ }
9
+ },
10
+ "chrome-devtools": {
11
+ "type": "stdio",
12
+ "command": "npx",
13
+ "args": ["-y", "chrome-devtools-mcp"],
14
+ "env": {}
15
+ }
16
+ }
17
+ }