create-rigline-plugin 1.0.0-alpha.13 → 1.0.0-alpha.14

package/README.md

@@ -3,7 +3,7 @@
 Scaffolds a workspace for [Rigline](https://github.com/Rigline/Rigline) plugins — plugins for the
 Claude Code VS Code extension.
 
-    npm create rigline-plugin my-plugins
+    npm create rigline-plugin my-plugin
 
 A plugin runs inside a modification of Anthropic's extension, so the
 [plugin policy](https://github.com/Rigline/Rigline/blob/main/docs/plugin-policy.md) applies to it —
@@ -15,17 +15,19 @@ A pnpm workspace with `plugins/*` and one plugin in it, rather than a single-plu
 multi-plugin shape scaffolds correctly for one plugin and a second is then a directory copy, where a
 single-plugin template could not grow into a workspace without a restructure.
 
-    my-plugins/
+    my-plugin/
       generated.ts              the harvested identifiers, shared by every plugin here
       pnpm-workspace.yaml       with the supply-chain settings written down rather than inherited
-      tsconfig.base.json        pulls the root harvest into every plugin's program
+      tsconfig.base.json        the compiler settings every plugin shares
+      tsconfig.plugin.json      pulls the root harvest into every plugin's program
       plugins/my-plugin/
         rigline.json            what the plugin declares it needs from the extension
-        src/index.ts            the plugin
+        src/index.tsx           the plugin
         src/index.test.ts
 
 Then:
 
+    cd my-plugin
     pnpm install
     pnpm codegen                # harvest your installed extension, and commit the result
     pnpm build
@@ -46,8 +48,8 @@ and the diff when you run against a newer extension is how you find out what mov
 
 The identifiers are harvested once, at the root, and imported by every plugin in the repository,
 because they all compile against the same installed extension. Module augmentation is per-program,
-so each plugin's tsconfig has to pull that harvest in — which the shared base config does, and which
-is the one ordering dependency in the whole arrangement.
+so each plugin's tsconfig has to pull that harvest in — which `tsconfig.plugin.json`, the config each
+plugin extends, does, and which is the one ordering dependency in the whole arrangement.
 
 [Authoring guide](https://github.com/Rigline/Rigline/blob/main/docs/authoring.md)
 

package/dist/bin.js

@@ -0,0 +1,4 @@
+#!/usr/bin/env node
+import { main } from "./index.js";
+process.exitCode = main(process.argv.slice(2));
+//# sourceMappingURL=bin.js.map

package/dist/index.js

@@ -1,4 +1,3 @@
-#!/usr/bin/env node
 import { existsSync, mkdirSync, readdirSync, readFileSync, writeFileSync } from "node:fs";
 import { basename, dirname, join, relative, resolve } from "node:path";
 import { fileURLToPath } from "node:url";
@@ -132,7 +131,4 @@ const USAGE = `create-rigline-plugin
 
 Scaffolds a pnpm workspace holding one Rigline plugin. The directory's own name is the plugin's
 unless --name says otherwise; a second plugin later is a copy of the first.`;
-if (process.argv[1] !== undefined && fileURLToPath(import.meta.url) === resolve(process.argv[1])) {
-    process.exitCode = main(process.argv.slice(2));
-}
 //# sourceMappingURL=index.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-rigline-plugin",
-  "version": "1.0.0-alpha.13",
+  "version": "1.0.0-alpha.14",
   "description": "Scaffold a workspace for Claude Code VS Code extension plugins",
   "keywords": [
     "rigline",
@@ -29,10 +29,10 @@
     "template"
   ],
   "bin": {
-    "create-rigline-plugin": "./dist/index.js"
+    "create-rigline-plugin": "./dist/bin.js"
   },
   "devDependencies": {
-    "@rigline/plugin-api": "1.0.0-alpha.13"
+    "@rigline/plugin-api": "1.0.0-alpha.14"
   },
   "scripts": {
     "build": "node ../../scripts/clean-dist.mjs && tsc -p tsconfig.build.json",

package/template/.gitattributes

@@ -0,0 +1,7 @@
+# LF in the repository, and each platform's own line endings in the working tree, so a diff never
+# depends on who checked the file out.
+* text=auto
+
+# Written by `pnpm codegen`, so review tools collapse it. Still diffed: after a Claude Code update,
+# its diff is how you see what moved.
+generated.ts linguist-generated

package/template/.github/workflows/ci.yml

@@ -37,14 +37,14 @@ jobs:
         # claim to match, because a floor nothing runs on is a guess.
         node: ["22.12.0", "24", "26"]
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v7
 
       # Pinned exactly rather than to the major: this action's `v6` tag still resolves to the last
       # release before pnpm v12 support, and `v4` runs on a runner runtime GitHub has deprecated.
       - uses: pnpm/action-setup@v6.1.0
 
       # After pnpm, never before: `cache: pnpm` asks pnpm where its store is.
-      - uses: actions/setup-node@v5
+      - uses: actions/setup-node@v7
         with:
           node-version: ${{ matrix.node }}
           cache: pnpm

package/template/.github/workflows/release.yml

@@ -2,15 +2,15 @@
 #
 # GitHub authenticates to npm over OIDC, so the secret this workflow would otherwise need does not
 # exist. What it does is *stage*: a staged version sits in a queue that nobody can install until you
-# approve it from your own machine with 2FA. Approving says you meant to ship it.
-#
-#     pnpm stage approve
+# approve it with your second factor. Approving says you meant to ship it. Approve on npmjs.com,
+# under your profile's Staged Packages, or with `npm stage approve <id>` (`npm stage list` shows the
+# ids); `pnpm stage approve` asks for a typed code, which a security key cannot give.
 #
 # Before this works, once per package, on npmjs.com:
 #
 #   1. Publish the first version by hand. A package that does not exist yet has nothing for a
-#      trusted publisher to attach to: `pnpm publish -r --otp <code>` (a one-time password, not a
-#      token — there is then nothing to store or revoke).
+#      trusted publisher to attach to: `pnpm build`, then `npm publish` in the plugin's directory,
+#      which opens a browser for your second factor (no token, so nothing to store or revoke).
 #   2. Add a trusted publisher under the package's settings, naming this repository and this file
 #      by path. Renaming this file breaks the exchange until the entry is edited to match.
 #      Set its permission to stage-only.
@@ -56,7 +56,7 @@ jobs:
           echo "::error::Releases go from ${{ github.event.repository.default_branch }}."
           exit 1
 
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v7
 
       # npm binds a provenance attestation to the package's `repository` field, so a package
       # without one cannot be staged with `--provenance` at all. Asked here, before the build, so
@@ -82,7 +82,7 @@ jobs:
       # Pinned exactly rather than to the major: this action's `v6` tag still resolves to the last
       # release before pnpm v12 support, and `v4` runs on a runner runtime GitHub has deprecated.
       - uses: pnpm/action-setup@v6.1.0
-      - uses: actions/setup-node@v5
+      - uses: actions/setup-node@v7
         with:
           node-version: 26
           cache: pnpm
@@ -107,6 +107,8 @@ jobs:
       # went up and the one command that finishes the job.
       - name: Summarise
         if: always()
+        env:
+          DRY_RUN: ${{ inputs.dry_run }}
         run: |
           if [ ! -f pnpm-publish-summary.json ]; then
             echo "## Nothing was staged" >> "$GITHUB_STEP_SUMMARY"
@@ -118,13 +120,15 @@ jobs:
             const s = JSON.parse(require("fs").readFileSync("pnpm-publish-summary.json", "utf8"));
             const out = [];
             const staged = s.publishedPackages ?? [];
+            const table = ["| package | version |", "| --- | --- |", ...staged.map((p) => `| \`${p.name}\` | \`${p.version}\` |`)];
             if (staged.length === 0) {
               out.push("## Nothing was staged", "", "Every version is already on the registry. Bump one to release it.");
+            } else if (process.env.DRY_RUN === "true") {
+              out.push("## Dry run: nothing was staged", "", "A run without the dry run would stage these:", "", ...table);
             } else {
-              out.push("## Staged, and awaiting approval", "", "| package | version |", "| --- | --- |");
-              for (const p of staged) out.push(`| \`${p.name}\` | \`${p.version}\` |`);
-              out.push("", "**Nobody can install these yet.** On a machine with your npm 2FA:", "", "```", "pnpm stage approve", "```", "",
-                "It lists what is queued and takes the batch under one one-time password. A version you would rather not ship needs no action — do not approve it, and it expires.");
+              out.push("## Staged, and awaiting approval", "", ...table);
+              out.push("", "**Nobody can install these yet.** Approve them on npmjs.com, under Staged Packages in your profile, or from a terminal:", "", "```", "npm stage list", "npm stage approve <id>", "```", "",
+                "A version you would rather not ship needs no action — do not approve it, and it expires.");
             }
             require("fs").appendFileSync(process.env.GITHUB_STEP_SUMMARY, out.join("\n") + "\n");
           '

package/template/README.md

@@ -23,7 +23,7 @@ you run against a newer extension, and the diff is how you find out what moved.
 
     pnpm rigline dev plugins/__NAME__
 
-Rebuilds and re-injects on every save. Reload webviews to see each change.
+Rebuilds, installs the build and re-injects on every save. Reload webviews to see each change.
 
 ## What a plugin declares
 
@@ -65,8 +65,9 @@ lands in the right place, survives a re-render, or costs a row a line of height
 the app can answer: build, add, reload, look.
 
 `.github/workflows/ci.yml` runs typecheck, build and test on every push and every pull request,
-over three Node versions — the same set the release workflow runs, so nothing reaches a release
-that a pull request would not already have failed on. Commit `pnpm-lock.yaml`: CI installs what it
+over three Node versions. The release workflow runs the same three steps again on the newest of
+them before it stages anything, so nothing reaches a release that a pull request would not already
+have failed on. Commit `pnpm-lock.yaml`: CI installs what it
 says rather than resolving its own.
 
 ## Publishing
@@ -78,9 +79,10 @@ and both `@rigline/core` and `@rigline/plugin-api` stay *devDependencies*.
 
 `.github/workflows/release.yml` does it from CI, with no npm token stored anywhere: GitHub
 authenticates to npm over OIDC, and what the workflow does is *stage* — a version nobody can
-install until you approve it from your own machine with 2FA.
-
-    pnpm stage approve
+install until you approve it with your second factor. Approve on npmjs.com, under your profile's
+*Staged Packages*, which lists what is waiting; or from a terminal, `npm stage list` then
+`npm stage approve <id>`. Not `pnpm stage approve`: it asks for a typed one-time password, which a
+security key — the only second factor npm still enrols — cannot give.
 
 **One field to fill in before the first publish: `repository`.** npm binds a provenance attestation
 to it, and this workflow stages with provenance, so a package without one cannot be staged at all.
@@ -99,9 +101,9 @@ MIT, and npm ships a licence file whatever `files` says, so adding one is the wh
 `rigline-plugin` keyword is already there: it is how somebody finds a plugin on npm.
 
 Two things to set up once per package, the first time. Publish version one by hand, because a
-package that does not exist yet has nothing for a trusted publisher to attach to — `pnpm publish -r
---otp <code>`, supplying a one-time password rather than creating a token, so there is nothing to
-store or to revoke afterwards. Then add a trusted publisher in the package's settings on npmjs.com,
+package that does not exist yet has nothing for a trusted publisher to attach to: `pnpm build`, then
+`npm publish` in the plugin's directory, which opens your browser for the second factor rather than
+needing a token, so there is nothing to store or to revoke afterwards. Then add a trusted publisher in the package's settings on npmjs.com,
 naming this repository and `release.yml` by path, with its permission set to stage-only. The
 workflow's own header repeats both, where you will be when you need them.
 

package/template/plugins/__NAME__/tsconfig.json

@@ -1,5 +1,4 @@
 {
   "extends": "../../tsconfig.plugin.json",
-  "include": ["src/**/*.ts", "src/**/*.tsx"],
-  "exclude": ["src/**/*.test.ts"]
+  "include": ["src/**/*.ts", "src/**/*.tsx"]
 }