@slbdn/mcp-tester 1.6.0 → 1.7.0

package/CHANGELOG.md

@@ -7,6 +7,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.7.0] - 2026-10-23
+
+### Added
+- `npm run release -- <patch|minor|major|prerelease>` — a one-command release tool that runs a strict pre-flight (clean tree, origin sync, no dangling tags, `npm@10` lockfile check, `npm@10` audit, full local gates, version sanity, non-empty `[Unreleased]`) and then bumps the version, promotes the CHANGELOG, commits `chore: release <x.y.z>`, and creates a lightweight `v<x.y.z>` tag. `--dry-run` runs every gate and prints the plan without writing. Every gate maps to a real incident (1.5.0 audit, 1.5.1 / 1.6.0 emnapi lockfile trap, v1.5.5 fold); see `docs/plans/release-automation.md` and `docs/releases.md`. Zero new runtime deps; pure library in `scripts/release-lib.mjs`, orchestrator in `scripts/release.mjs`, 39 `node:test` cases in `scripts/release.test.mjs` run by `npm run test:release` (wired into CI). Replaces the old `npm version`-based `release:patch/minor/major/prerelease` scripts (the new aliases delegate to the script).
+- The release tool's pre-flight is a strict superset of the gates `release.yml` runs, so a green pre-flight ≈ a green publish. Interrupted runs are detected and resumed safely — a re-run re-verifies the gates and completes only the missing tag, never re-applying the bump or changelog promotion — and any failure path rolls back every partial write (including staged content).
+- `--dry-run` and exit codes (0 ok / 1 gate failed / 2 usage error) make the tool safe to call from scripts.
+
+### Fixed
+- The release workflow's post-publish verification no longer fails on npm registry propagation lag. `npm publish` is eventually consistent — a version published seconds earlier can still 404 via CDN negative caching — so the `verify` job now polls `npm view` until the version is visible (up to 10 minutes) and retries the install a few times instead of failing the run. Previously the job had to be manually re-run a few minutes later to go green.
+- Running the CLI test suite no longer leaks the child process's deliberate error output (e.g. `❌ Framework must be "jest" or "vitest"` from the invalid-flag test) into the Jest log — every spawned CLI invocation now pipes its output. A passing suite printed as if it had errors; it did this twice per release run.
+
+### Security
+- `markdown-it` 14.3.2 → 14.3.3 (GHSA-vfgh-jcmw-g37q, GHSA-gfr2-rv44-r23c — quadratic-time DoS; dev-only, via TypeDoc) and `ip-address` 10.7.3 → 10.7.4 (GHSA-rxp7-6hxx-x8q5; dev-only, via the SDK's express-rate-limit). `npm audit` is now clean at the `high` threshold. Notably, the release tool's own P5 audit gate caught this locally before tagging — the same failure class that blocked the 1.5.0 release in CI.
+
 ## [1.6.0] - 2026-10-08
 
 ### Added

package/README.md

@@ -617,12 +617,14 @@ mcp-tester/
 ## Development
 
 ```bash
-npm install          # Install dependencies
-npm run build        # Compile TypeScript
-npm run dev          # Watch mode — auto-rebuild on source changes
-npm test             # Run tests (auto-generates reports/test-report.html)
-npm run lint         # Lint code
-npm run format       # Format with Prettier
+npm install              # Install dependencies
+npm run build            # Compile TypeScript
+npm run dev              # Watch mode — auto-rebuild on source changes
+npm test                 # Run tests (auto-generates reports/test-report.html)
+npm run test:browser     # Smoke-test the browser bundle (esbuild, platform: 'browser')
+npm run lint             # Lint code
+npm run format           # Format with Prettier
+npm run release -- patch # Cut a release (see docs/releases.md)
 ```
 
 ## Troubleshooting

package/docs/releases.md

@@ -1,413 +1,156 @@
 # Release Guide
 
-This guide explains how to create and publish new releases of MCP Tester.
+How to create and publish a new release of `mcp-tester`. The release tool (`npm run release`) does the version bump, CHANGELOG promotion, commit, and tag in one command — and runs a strict pre-flight that catches every issue we've shipped broken before (audit failures, npm 11 lockfile traps, dangling local tags, empty `[Unreleased]`).
 
-## Prerequisites
+## Prerequisites (one-time)
 
-1. **NPM Token Setup**
-   - Go to [npmjs.com](https://www.npmjs.com/settings/tokens)
-   - Create a new automation token
-   - Add it to GitHub repository secrets as `NPM_TOKEN`
-     - Navigate to: Repository Settings → Secrets and variables → Actions
-     - Click "New repository secret"
-     - Name: `NPM_TOKEN`
-     - Value: Your npm automation token
+1. **NPM Token**
+   - Go to <https://www.npmjs.com/settings/tokens> and create an **Automation** token.
+   - Add it to the repository as the secret `NPM_TOKEN` (Settings → Secrets and variables → Actions → New repository secret).
+2. **GitHub Actions** — `GITHUB_TOKEN` is automatic; `release.yml` already has `contents: write` for releases and `id-token: write` for provenance (if enabled).
+3. **Local git** — `git push` permission for `main` and tags. The release script never pushes; you do that after the script finishes.
 
-2. **GitHub Token**
-   - The `GITHUB_TOKEN` is automatically provided by GitHub Actions
-   - Ensure the workflow has permission to create releases (already configured)
-
-## Release Process
-
-### Option 1: Quick Release (Recommended)
-
-Use this for routine releases (patch, minor, or major version bumps):
-
-```bash
-# For patch release (1.0.0 → 1.0.1)
-npm run release:patch
-
-# For minor release (1.0.0 → 1.1.0)
-npm run release:minor
-
-# For major release (1.0.0 → 2.0.0)
-npm run release:major
-
-# For prerelease (1.0.0 → 1.0.1-beta.0)
-npm run release:prerelease
-```
-
-Then commit and create tag:
-
-```bash
-# Commit the version bump and CHANGELOG updates
-npm run release:commit
-
-# Create and push the tag
-git tag v$(node -p "require('./package.json').version")
-git push origin main --tags
-```
-
-The release workflow will automatically:
-- ✅ Verify version matches tag
-- ✅ Run tests across Node.js versions (20, 22)
-- ✅ Build the project
-- ✅ Run security audits
-- ✅ Publish to npm
-- ✅ Create GitHub release with notes from CHANGELOG
-- ✅ Upload coverage to Codecov
-
-### Option 2: Manual Release
-
-For full control over the release process:
+## The release process
 
 ```bash
-# 1. Update version in package.json
-npm version patch  # or minor, major, prerelease
-
-# 2. Update CHANGELOG.md
-#    - Move items from [Unreleased] to new version section
-#    - Add date to version header: ## [1.0.1] - 2025-01-20
-#    - Keep [Unreleased] section for next changes
-
-# 3. Verify tests pass
-npm test
+# 1. Make sure your tree is ready:
+#    - the [Unreleased] section of CHANGELOG.md has the entries you want to ship
+#    - everything you want in the release is committed and pushed
+git push origin main
 
-# 4. Build project
-npm run build
+# 2. Run the release script (add --dry-run first if you want a no-write preview)
+npm run release -- minor
+#    alias scripts: release:patch, release:minor, release:major, release:prerelease
 
-# 5. Commit changes
-git add package.json CHANGELOG.md
-git commit -m "chore: release v1.0.1"
-
-# 6. Create and push tag
-git tag v1.0.1
-git push origin main --tags
+# 3. The script prints the push command when it succeeds:
+#      git push origin main --tags
+#    Run that. release.yml takes over from there.
 ```
 
-### Option 3: Custom Version
+The script:
 
-To set a specific version:
+1. Runs a strict pre-flight (next section). If anything is off, it exits 1 with an actionable message and writes nothing.
+2. Bumps the version in `package.json` and the two `version` lines in `package-lock.json` (direct JSON edit — **never** `npm version`, which has produced lockfile churn in the past).
+3. Promotes `## [Unreleased]` to `## [<version>] - <today>` in `CHANGELOG.md`, byte-for-byte preserving the rest.
+4. Verifies the resulting `git diff` is exactly the 3 expected files with the expected line counts.
+5. Creates the commit `chore: release <version>` and a lightweight tag `v<version>`.
+6. Prints the push handoff.
 
-```bash
-# Set specific version
-npm version 1.2.3
-
-# Update CHANGELOG.md manually
-# ... edit CHANGELOG.md ...
-
-# Commit
-git add package.json CHANGELOG.md
-git commit -m "chore: release v1.2.3"
-
-# Create tag and push
-git tag v1.2.3
-git push origin main --tags
-```
-
-## Version Numbering
-
-Follow [Semantic Versioning](https://semver.org/):
-
-- **MAJOR** (X.0.0): Breaking changes or major features
-  - Example: 1.0.0 → 2.0.0
-  - Use when: API changes that break compatibility
-
-- **MINOR** (0.X.0): New features, backward compatible
-  - Example: 1.0.0 → 1.1.0
-  - Use when: Adding new features without breaking changes
-
-- **PATCH** (0.0.X): Bug fixes
-  - Example: 1.0.0 → 1.0.1
-  - Use when: Fixing bugs without adding features
-
-- **PRERELEASE** (0.0.0-X): Pre-release versions
-  - Example: 1.0.0 → 1.1.0-alpha.1
-  - Use when: Testing unreleased features
-
-## Pre-Release Checklist
-
-Before creating a release:
-
-### 1. Update CHANGELOG.md
-```markdown
-## [1.0.1] - 2025-01-20
-
-### Added
-- New feature X
-
-### Fixed
-- Bug Y fixed
-
-### Changed
-- Updated dependency Z
-
-## [Unreleased]
-
-### Added
-- Next feature A (stays here)
-```
+Nothing is pushed, nothing is published. You can inspect the commit with `git show`, the diff with `git show v<version>`, and the tag with `git tag -l`. If anything looks wrong, abort the release with `git reset --hard HEAD~1 && git tag -d v<version>`.
 
-### 2. Run Tests
-```bash
-npm test
-npm run test:coverage
-```
+## The pre-flight gates (P1–P8)
 
-### 3. Verify Build
-```bash
-npm run build
-npm run lint
-npm run format:check
-```
+Each gate maps to a real incident. If any fails, the script exits 1 with the failing gate, why it failed, and the manual command to re-run for the real error output.
 
-### 4. Check Dependencies
-```bash
-npm audit
-npm outdated
-```
+| Gate | Checks | Incident it would have caught |
+|---|---|---|
+| **P1** | Working tree is clean | (always; you can't cut a release on dirty code) |
+| **P2** | `HEAD` is at the tip of `origin/main` (no unpushed, no unpulled commits) | The 1.6.0 fold — release tag lived on unpushed commits |
+| **P3** | Every local `v*` tag exists on `origin` (peeks `^{commit}` to match the remote's peeled entry) | Same — would have caught `v1.5.5` as dangling before publish |
+| **P4** | Lockfile is installable by `npm@10` (run in a temp dir; CI's npm) | The 1.5.1 + 1.6.0 emnapi trap — `npm audit fix` under npm 11 has twice produced locks npm 10 cannot install |
+| **P5** | `npm@10 audit --audit-level=high` exits 0 | 1.5.0 publish failure (SDK OAuth + proxy-addr) |
+| **P6** | Full local gates: `build`, `lint`, `format:check`, `test:browser`, `test`, `test:coverage`, `test:package` | Surfaces anything `release.yml` will run, locally, in ~6 min |
+| **P7** | New version `N` is strictly greater than published `P`; no local tag `v{N}`; not on the registry | Re-releasing the same version; double-tagging |
+| **P8** | `## [Unreleased]` exists in `CHANGELOG.md` and contains at least one content line | The v1.5.5 fold — release with nothing in it |
 
-### 5. Review Documentation
-- [ ] README.md is up to date
-- [ ] CHANGELOG.md includes all changes
-- [ ] Examples work correctly
-- [ ] API documentation is accurate
+Use `npm run release -- <bump> --dry-run` to run every gate and print the planned version / date / diff preview without writing anything.
 
-### 6. Verify Version
-```bash
-npm version patch  # This updates package.json
-cat package.json | grep version
-```
+## How the CI publish works (so you know what to expect)
 
-## Release Workflow
+Pushing `main` + the new `v<x.y.z>` tag triggers `.github/workflows/release.yml`, which:
 
-When you push a version tag (e.g., `v1.0.1`), the release workflow:
+1. **Verifies** the tag version matches `package.json` (refuses to publish a misaligned tag).
+2. **Runs gates on Node 20 / npm 10** — `npm ci`, `npm audit --audit-level=high` (hard gate), `build`, `lint`, `format:check`, `test`, `coverage`.
+3. **Publishes** to npm with provenance, creates the GitHub release from the CHANGELOG section that was just promoted, uploads coverage to Codecov.
+4. **Verifies** the install from the registry. This job now waits up to 10 minutes for the version to become visible (npm is eventually consistent) and retries the install (see commit `24fee8d`).
 
-1. **Trigger**: Starts automatically on tag push
-2. **Verify**: Confirms tag version matches package.json
-3. **Test**: Runs all tests across Node.js 20, 22
-4. **Build**: Compiles TypeScript to JavaScript
-5. **Audit**: Runs security audits
-6. **Lint**: Checks code quality
-7. **Publish**: Publishes package to npm registry
-8. **Release**: Creates GitHub release with CHANGELOG notes
-9. **Verify**: Verifies package can be installed from npm
+If step 2 fails after the tag is pushed, fix the issue and cut a **new** release with the script — do not rewrite the tag, do not re-run the workflow.
 
-## Monitoring Release Progress
+## Versioning
 
-After pushing the tag:
+[Semantic Versioning](https://semver.org/):
 
-1. Go to: `https://github.com/islobodan/mcp-tester/actions`
-2. Click on the "Release" workflow run
-3. Monitor the progress through each step
+- **MAJOR** — breaking API change. Use sparingly.
+- **MINOR** — new capability, backward compatible (browser support, new transport, new matcher).
+- **PATCH** — bug fix, no public surface change (workflow fix, lockfile bump, doc fix).
+- **PRERELEASE** — opt-in / experimental. The script supports `npm run release -- prerelease` and follows npm's `npm version prerelease` rules: `1.6.0` → `1.6.1-0`, `1.6.1-0` → `1.6.1-1`, `1.6.1-beta.0` → `1.6.1-beta.1`.
 
-Expected duration: ~5-8 minutes
+## Manual fallback (discouraged)
 
-## Post-Release
+If the release script can't run for some reason (e.g. you need to do a post-incident hotfix on a fresh clone with no network), the manual equivalent is:
 
-### 1. Verify on npm
 ```bash
-# Check if package is available
-npm view @slbdn/mcp-tester
-
-# Install and test
-npm install @slbdn/mcp-tester@latest
+# 1. Edit package.json "version" and the two version lines in package-lock.json
+#    (top-level + packages[""].version). Do NOT run `npm version` — it rewrites
+#    the lockfile through npm's own machinery and has produced churn before.
+# 2. Promote CHANGELOG.md by hand: `## [Unreleased]` → `## [N] - YYYY-MM-DD`.
+# 3. Commit and tag.
+git add package.json package-lock.json CHANGELOG.md
+git commit -m "chore: release N"
+git tag vN
+git push origin main --tags
 ```
 
-### 2. Verify GitHub Release
-- Go to: `https://github.com/islobodan/mcp-tester/releases`
-- Check release notes are correct
-- Verify release assets are attached
-
-### 3. Update Documentation
-- Update README.md if needed
-- Update examples if API changed
-- Update AGENTS.md with new features
-
-### 4. Announce Release
-- Create GitHub Discussion
-- Post issue about the release
-- Update project documentation
+If the script's pre-flight then fails on the *next* release, it's usually P4 (lockfile) — fix with `npx -y npm@10 install` (not `npm audit fix` under npm 11).
 
 ## Troubleshooting
 
-### Release Workflow Failed
+### Pre-flight says "tree is not clean"
 
-**Check:**
-1. Version tag format (must be `vX.Y.Z`)
-2. Version matches package.json exactly
-3. Tests are passing locally
-4. NPM_TOKEN is set correctly
+Commit, stash, or unstage the listed files. The script refuses to operate on a dirty tree because the `git diff --numstat` self-check needs a stable baseline.
 
-**Fix:**
-```bash
-# Delete and recreate tag
-git tag -d v1.0.1
-git push origin :refs/tags/v1.0.1
+### Pre-flight says "HEAD is N commit(s) ahead of origin/main"
 
-# Fix issues, then recreate
-git tag v1.0.1
-git push origin v1.0.1
-```
+You have local commits that aren't pushed. Either push them (`git push origin main`) and re-run, or reset them if you don't want them. The 1.5.5 fold was exactly this scenario.
 
-### NPM Publish Failed
+### Pre-flight P4 fails ("lockfile not installable by npm 10")
 
-**Check:**
-1. NPM_TOKEN has publish permissions
-2. Package name is not already taken
-3. Version doesn't already exist on npm
+`npm@10 ci --dry-run` returned non-zero in the temp dir. The most common cause is `npm audit fix` having been run under npm 11. Fix:
 
-**Fix:**
 ```bash
-# Verify token
-npm whoami
-
-# Check if version exists
-npm view @slbdn/mcp-tester@1.0.1
-
-# If version exists, increment it
-npm version patch
-git commit package.json -m "chore: increment version"
-git tag v1.0.2
-git push origin v1.0.2
+npx -y npm@10 install           # regenerate lock under npm 10
+# OR (if you actually want audit fixes)
+npx -y npm@10 audit fix
 ```
 
-### GitHub Release Not Created
+Then re-run the release script. See `docs/troubleshooting.md` for the full emnapi history.
 
-**Check:**
-1. GITHUB_TOKEN has write permissions
-2. Workflow has permission to create releases
-3. Tag format is correct
+### Pre-flight P5 fails (audit)
 
-**Fix:**
-- Manually create release from GitHub UI
-- Or delete tag and push again
+Same command `release.yml` will run. Run `npx -y npm@10 audit` to see what; bump or replace the offending dependency. If the advisory is in a transitive dep behind a dev-only package, the right fix is to bump the parent (e.g. `ts-jest` was the path that brought in `handlebars` for 1.6.0).
 
-### Tests Failing in CI
+### Pre-flight P8 fails ("nothing to release — [Unreleased] is empty")
 
-**Check:**
-1. All tests pass locally
-2. Node.js version compatibility
-3. Dependencies are installed correctly
+Add entries to `CHANGELOG.md` under `## [Unreleased]`, or skip this release. The script refuses to cut a release with an empty changelog because that's exactly the shape of the v1.5.5 fold.
 
-**Fix:**
-```bash
-# Clean and reinstall
-rm -rf node_modules package-lock.json
-npm install
+### Resume after an interrupted run
 
-# Run tests
-npm test
-```
+If the script died between the commit and the tag (e.g. lost connection), the next run detects the state — `package.json` is bumped, `CHANGELOG.md` has the new section, HEAD is `chore: release <N>`, but the tag is missing — and just creates the missing tag. Resume detection itself is a cheap local shape check (no network); the full pre-flight still runs in resume mode, with two deliberate exceptions: P2 (HEAD is necessarily ahead of `origin/main` — the release commit is about to be pushed) and P8 (the changelog is already promoted — that is the resume signal). `N > published P` is still verified in P7, and the release steps never re-run the bump/promotion (which is not idempotent).
 
-## Rollback Procedure
+### `release.yml` verify job fails
 
-If you need to rollback a release:
+`release.yml`'s verify job now waits up to 10 minutes for npm to propagate and retries the install (commit `24fee8d`). If it still fails, the package genuinely is not installable — check the workflow logs and treat as a real failure.
 
-### 1. Yank NPM Version
-```bash
-npm deprecate @slbdn/mcp-tester@1.0.1 "Release rollback due to bug"
-```
+### Tag exists locally but you want to redo the release
 
-### 2. Delete GitHub Release
-1. Go to repository releases page
-2. Edit or delete the release
-3. Delete the tag if needed
-
-### 3. Create Hotfix
 ```bash
-# Create hotfix branch
-git checkout -b hotfix/issue
-
-# Fix issue
-git commit -am "fix: critical bug"
-
-# Bump version
-npm version patch
-
-# Release
-git tag v1.0.2
-git push origin v1.0.2
-```
-
-## Best Practices
-
-1. **Update CHANGELOG First**
-   - Always update CHANGELOG.md before version bump
-   - Include all changes in the release
-   - Reference issues/PRs if helpful
-
-2. **Test Before Release**
-   - Run all tests locally
-   - Build the project
-   - Install and test locally
-
-3. **Use Semantic Versioning**
-   - MAJOR: Breaking changes
-   - MINOR: New features
-   - PATCH: Bug fixes
-
-4. **Tag Naming**
-   - Always use `v` prefix: `v1.0.1`
-   - Follow semver format: `vX.Y.Z`
-
-5. **Review Before Pushing**
-   - Check CHANGELOG is complete
-   - Verify version is correct
-   - Confirm tests pass
-
-6. **Monitor Release**
-   - Watch GitHub Actions workflow
-   - Check npm publication
-   - Verify GitHub release creation
-
-7. **Document Breaking Changes**
-   - Clearly document breaking changes in CHANGELOG
-   - Add migration guide if needed
-   - Update examples to use new API
-
-## Example: Complete Release Workflow
-
-```bash
-# 1. Update CHANGELOG.md
-# Edit CHANGELOG.md, move items from [Unreleased] to new version
-
-# 2. Bump version (patch release)
-npm run release:patch
-
-# 3. Verify tests pass
-npm test
-
-# 4. Build project
-npm run build
-
-# 5. Commit changes
-npm run release:commit
-
-# 6. Create and push tag
-VERSION=$(node -p "require('./package.json').version")
-git tag v$VERSION
-git push origin main --tags
-
-# 7. Monitor release at:
-# https://github.com/islobodan/mcp-tester/actions
+git tag -d vX.Y.Z
+git reset --hard HEAD~1   # undo the release commit
+# re-run: npm run release -- patch
 ```
 
-## Additional Resources
+Never push a deletion of a published tag without first unpublishing or deprecating that version on npm.
 
-- [Semantic Versioning](https://semver.org/)
-- [npm Publishing](https://docs.npmjs.com/cli/publish)
-- [GitHub Releases](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository)
-- [GitHub Actions](https://docs.github.com/en/actions)
+## Best practices
 
-## Support
+1. **Keep `[Unreleased]` flowing.** Add changelog entries with the code change, not in a separate prep step. The script's P8 gate makes this a hard requirement.
+2. **Push before you release.** The script's P2 + P3 gates enforce this; respect them.
+3. **One tag per push.** Two tag pushes launch two concurrent `release.yml` runs that both `npm publish`; npm `latest` will land on whichever finishes last (potentially the older one). If you accidentally cut two, see [docs/troubleshooting.md](./troubleshooting.md).
+4. **Use `--dry-run` on the first cut of a new release line** to sanity-check what would happen without writing anything.
+5. **Never run `npm version` against this repo's lockfile.** Use the script (which does direct JSON edits + a diff self-check) or the manual fallback.
 
-If you encounter issues with releases:
+## See also
 
-1. Check GitHub Actions logs for detailed error messages
-2. Review this guide's troubleshooting section
-3. Open an issue on GitHub with:
-   - Version being released
-   - Error messages
-   - Steps taken
-   - Expected vs actual behavior
+- [`docs/plans/release-automation.md`](./plans/release-automation.md) — the implementation spec, including the incident log that justifies every gate.
+- [`docs/troubleshooting.md`](./troubleshooting.md) — common failures and how to fix them.
+- [`CHANGELOG.md`](../CHANGELOG.md) — the changelog the script promotes.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slbdn/mcp-tester",
-  "version": "1.6.0",
+  "version": "1.7.0",
   "description": "Minimal MCP client implementation for CI/CD testing of MCP servers",
   "main": "dist/index.js",
   "browser": {
@@ -36,11 +36,12 @@
     "audit": "npm audit",
     "audit:fix": "npm audit fix",
     "prepublishOnly": "npm run build && npm run docs",
-    "release:patch": "npm version patch && npm run build",
-    "release:minor": "npm version minor && npm run build",
-    "release:major": "npm version major && npm run build",
-    "release:prerelease": "npm version prerelease && npm run build",
-    "release:commit": "git add package.json CHANGELOG.md && git commit -m \"chore: release $(node -p \"require('./package.json').version\")\"",
+    "release": "node scripts/release.mjs",
+    "release:patch": "node scripts/release.mjs patch",
+    "release:minor": "node scripts/release.mjs minor",
+    "release:major": "node scripts/release.mjs major",
+    "release:prerelease": "node scripts/release.mjs prerelease",
+    "test:release": "node --test scripts/release.test.mjs",
     "prepare": "husky || true"
   },
   "bin": {