@buildinternet/releases 0.61.0 → 0.62.1

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.
Files changed (2) hide show
  1. package/README.md +47 -211
  2. package/package.json +6 -6
package/README.md CHANGED
@@ -6,286 +6,122 @@
6
6
  [![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](./LICENSE)
7
7
  [![skills.sh](https://skills.sh/b/buildinternet/releases-cli)](https://skills.sh/buildinternet/releases-cli)
8
8
 
9
- The changelog & release-notes registry for developers and AI agents. A lean HTTP client for [releases.sh](https://releases.sh) search and browse release notes from GitHub, RSS/Atom/JSON feeds, and product changelog pages without any local infrastructure.
9
+ The changelog & release-notes registry for developers and AI agents a lean HTTP client for [releases.sh](https://releases.sh). Search and browse release notes from GitHub, RSS/Atom/JSON feeds, and product changelog pages, with no local infrastructure.
10
10
 
11
- The CLI talks to the hosted registry at `api.releases.sh`. Reader commands work out of the box with no configuration.
12
-
13
- > **Reader access is open; admin access is closed beta.** Search and browse need no account. You can mint a personal **read-only** API key with `releases login` (browser sign-in — see [Authentication](#authentication)). `releases admin …` commands need a **write/admin** key, which isn't self-serve yet — open an issue for early access. Everything below the install section assumes reader-only use unless stated otherwise.
11
+ The CLI talks to the hosted registry at `api.releases.sh`. **Search and browse work out of the box no account or config.** Sign in with `releases login` to follow orgs and products and get a personalized feed; it mints a personal **read-only** API key (and earns you higher rate limits as those roll out). Write/admin access (`releases admin …`) is a separate, closed beta — open an issue for early access.
14
12
 
15
13
  ## Install
16
14
 
17
- ### Homebrew (macOS / Linux)
18
-
19
- ```bash
20
- brew install buildinternet/tap/releases
21
- ```
22
-
23
- ### npm (macOS, Linux, Windows)
24
-
25
- ```bash
26
- npm install -g @buildinternet/releases
27
- ```
28
-
29
- Or run without installing:
30
-
31
- ```bash
32
- npx @buildinternet/releases@latest search "react"
33
- ```
34
-
35
- Always include the `@latest` tag — bare `npx @buildinternet/releases` caches the first-fetched version forever and won't pick up updates.
36
-
37
- ### Shell installer (macOS, Linux)
38
-
39
- ```bash
40
- curl -fsSL https://releases.sh/install | bash
41
- ```
42
-
43
- Downloads the matching platform binary from npm. Respects `RELEASES_INSTALL_DIR` (default: `/usr/local/bin`). Windows users should use npm or the GitHub Releases archive below.
44
-
45
- ### Precompiled binaries (GitHub Releases)
46
-
47
- Every version publishes signed archives for each platform on the [Releases page](https://github.com/buildinternet/releases-cli/releases) — `releases-{darwin-arm64,darwin-x64,linux-arm64,linux-x64}.gz` and `releases-windows-x64.zip`, each with a matching `.sha256` and a top-level `checksums.txt`. Useful for air-gapped installs, version pinning, or platforms where npm and Homebrew aren't an option.
48
-
49
- ### Shell completion
50
-
51
- **Homebrew installs bash, zsh, and fish completions automatically** — nothing extra to do. For every other install path (npm, the `curl | bash` installer, and the raw GitHub binaries), enable completions once:
52
-
53
15
  ```bash
54
- releases completion install # auto-detects $SHELL
55
- releases completion install zsh # or pick explicitly
16
+ brew install buildinternet/tap/releases # Homebrew (macOS / Linux)
17
+ npm install -g @buildinternet/releases # npm (macOS / Linux / Windows)
18
+ curl -fsSL https://releases.sh/install | bash # shell installer (macOS / Linux)
56
19
  ```
57
20
 
58
- `install` writes to the conventional location (`~/.zsh/completions/_releases`, `~/.local/share/bash-completion/completions/releases`, or `~/.config/fish/completions/releases.fish`) and prints any rc-file lines you may need to add. The bash and fish paths honor `$XDG_DATA_HOME` and `$XDG_CONFIG_HOME` respectively, so the file lands wherever those point if set. Pass `--path <file>` to override the destination. To pipe the script somewhere yourself:
59
-
60
- ```bash
61
- releases completion zsh > /path/to/_releases
62
- ```
21
+ Or run without installing: `npx @buildinternet/releases@latest search react` always pin `@latest`, since bare `npx @buildinternet/releases` caches the first-fetched version forever. Signed, precompiled binaries for every platform are on the [Releases page](https://github.com/buildinternet/releases-cli/releases) (with checksums) for air-gapped installs or version pinning.
63
22
 
64
- On an interactive terminal, a persistent, self-resolving notice on the landing screen and `--help` reminds you to run this until shell completion is detected — and stops on its own once completions are set up (including the automatic Homebrew install). Set `RELEASES_NO_COMPLETION_HINT=1` to silence it.
23
+ Homebrew installs shell completions automatically. On every other path, enable them once with `releases completion install` (auto-detects `$SHELL`).
65
24
 
66
25
  ## Usage
67
26
 
68
27
  ```bash
69
28
  releases search "authentication"
70
- releases search "slack integration" --since 90d # filter release hits by publish date
71
- releases tail next-js # or `releases tail -f` to follow new releases
72
- releases tail src_abc123 # IDs work everywhere a slug does
73
- releases tail --since 30d # only releases from the last 30 days
29
+ releases search "slack integration" --since 90d # bound release hits by publish date
30
+ releases tail next-js # latest releases; `tail -f` to follow
74
31
  releases list --category ai
75
- releases get vercel # org, product, or source
76
- releases get org_abc123 # typed IDs are accepted
77
- releases org overview vercel # full AI-generated overview for an org
32
+ releases get vercel # org, product, or source
33
+ releases org overview vercel # full AI-generated org overview
78
34
  releases stats
79
- releases submit https://acme.dev/changelog # suggest a source for the registry
80
- releases feedback "great tool, here's an idea…" # send feedback to the maintainers
35
+ releases submit https://acme.dev/changelog # suggest a source for the registry
36
+ releases feedback "great tool here's an idea…" # message the maintainers
81
37
  ```
82
38
 
83
- Every command that takes an org / product / source / release identifier accepts the typed ID form (`org_…`, `prod_…`, `src_…`, `rel_…`) interchangeably with the slug. IDs are stable across renames; slugs are friendlier when typing. Sources and products also accept the `org/slug` coordinate form (e.g. `vercel/next-js`).
84
-
85
- `search` and `tail`/`latest` accept `--since` and `--until` to bound releases by publish date — an ISO date (`2026-01-01`) or relative shorthand (`90d`, `4w`, `6m`, `2y`). On `search` the window applies to release hits only.
86
-
87
- Every reader command supports `--json` for machine-readable output. List commands emit a `{ items, pagination }` envelope — parse with `jq '.items[]'`, and check `.pagination.hasMore` before assuming you've seen every row. Nested `metadata` fields are returned as parsed objects (no `fromjson` needed). `org get` includes a short overview preview (with a stale warning when more than 30 days old); `org overview <identifier>` prints the full body.
39
+ Identifiers are interchangeable: every command accepts a slug, a typed ID (`org_…`, `prod_…`, `src_…`, `rel_…`), or an `org/slug` coordinate (e.g. `vercel/next-js`). IDs are stable across renames. `search`, `tail`/`latest`, and `feed` take `--since` / `--until` to bound releases by date — an ISO date (`2026-01-01`) or relative shorthand (`90d`, `4w`, `6m`, `2y`).
88
40
 
89
- The release reader commands (`get`, `search`, `tail`/`latest`) return a **slim** release shape by default — `id`, `version`, `title`, `summary`, a markdown-stripped `excerpt`, `url`, `publishedAt`, nested `source`/`org`, and `contentChars`/`contentTokens` size hints so agents aren't billed tokens for storage/pipeline internals. Pass `--full` to recover the complete payload (`content`, `contentHash`, `composition`, the `title*` variants, …). Note this is the inverse of the catalog `list` command, which is verbose by default and opts _into_ a lightweight shape with `--compact`.
90
-
91
- Tabular reader commands fit themselves to the terminal width when stdout is a TTY (column truncation with `…`) and switch to bare TSV when piped — no headers, no color, no truncation — so `releases org list | cut -f2` works without parsing ANSI. `COLUMNS=<n>` overrides the detected width. For complete, parseable output prefer `--json`. The `search` / `tail`/`latest` human view is a single aligned row per release (identity · description · relative age · dimmed `rel_…`); `search` adds a cleaned, markdown-stripped excerpt under each hit.
41
+ Add `--json` to any reader command for machine-readable output — list commands emit a `{ items, pagination }` envelope. Release readers return a slim shape by default (id, version, title, summary, excerpt, url, dates, plus any `media` with its `r2Url`); pass `--full` for the complete payload. `tail`/`latest` take `--count` (alias `--limit`, 1–100). Run `releases <command> --help` for per-command flags.
92
42
 
93
43
  ### Following & personalized feed
94
44
 
95
- Follow organizations and products to build a personalized release feed. These act on your own account, so they need a signed-in CLI — run `releases login` first (or set `RELEASES_API_KEY`).
45
+ Follow orgs and products to build a personalized feed. These act on your own account, so sign in first (`releases login`):
96
46
 
97
47
  ```bash
98
- releases follow vercel # an org slug…
99
- releases follow vercel/next-js # …an org/product coordinate…
100
- releases follow prod_abc123 # …or a typed ID
48
+ releases follow vercel # org slug, org/product coordinate, or typed ID
101
49
  releases following # list what you follow
102
- releases feed # your personalized release timeline
103
- releases feed --limit 50 --page 2 # paginate (also --json)
50
+ releases feed # your release timeline (--json, --page, --limit)
104
51
  releases unfollow vercel
105
52
  ```
106
53
 
107
- Following an organization includes all of its products. `feed` renders like `tail` (one aligned row per release, `--json` for machine output) and is page-paginated.
108
-
109
- ### Feedback
110
-
111
- Tell the maintainers about a bug, an idea, or anything else. No API key or account required:
112
-
113
- ```bash
114
- releases feedback "tail -f reconnects slowly on flaky wifi" # one-shot message
115
- releases feedback --type bug # prompt for the text (interactive)
116
- echo "longer write-up…" | releases feedback # pipe from stdin
117
- releases feedback "love the tool" --contact you@example.com # optional reply-to
118
- releases feedback "draft" --dry-run --json # preview the payload, send nothing
119
- ```
120
-
121
- With no message argument in an interactive terminal, `feedback` prompts for the text (and an optional contact); otherwise pass it inline or pipe via stdin. `--type` accepts `bug`, `idea`, or `other`. Maintainers with admin access review submissions via `releases admin feedback list` (filter by `--type` / `--status`, `--include-archived`, paginate with `--cursor`) and triage them: `releases admin feedback triage <id> --status closed`, `releases admin feedback archive <id>` (`--undo` to restore), and `releases admin feedback delete <id>` (permanent — type the id to confirm, or pass `--yes`).
54
+ Following an organization includes all of its products.
122
55
 
123
- ### Submit a source
56
+ ### Contribute to the registry
124
57
 
125
- Suggest a changelog or release-notes URL for the registry — the same review queue the [web submit form](https://releases.sh/submit) feeds. No API key or account required:
58
+ Neither needs an account or API key:
126
59
 
127
60
  ```bash
128
- releases submit https://acme.dev/changelog # one-shot
129
- releases submit acme.dev/changelog # scheme optional https:// is assumed
130
- releases submit # prompt for the URL (interactive)
131
- echo "https://acme.dev/releases" | releases submit # pipe from stdin
132
- releases submit https://acme.dev/changelog --note "GitHub: acme/acme" --contact you@example.com
133
- releases submit https://acme.dev/changelog --dry-run --json # preview the payload, send nothing
61
+ releases submit https://acme.dev/changelog # suggest a changelog / release-notes URL
62
+ releases feedback "tail -f reconnects slowly" # report a bug or share an idea
134
63
  ```
135
64
 
136
- Index pages, changelogs, GitHub releases, and feed URLs are all ideal. `--note` carries extra context (product name, GitHub repo, feed quirks) and `--contact` is an optional email to notify once it's reviewed. With no URL argument in an interactive terminal, `submit` prompts for it (and the optional note/contact); otherwise pass it inline or pipe via stdin. Maintainers with admin access review the queue via `releases admin recommendations list` (filter by `--status` / `--type`, `--include-archived`, paginate with `--cursor`) and triage them: `releases admin recommendations triage <id> --status closed`, `releases admin recommendations archive <id>` (`--undo` to restore), and `releases admin recommendations delete <id>` (permanent type the id to confirm, or pass `--yes`).
65
+ Both prompt interactively when run with no argument, accept input on stdin, and take `--dry-run --json` to preview the payload without sending. `feedback --type` is `bug` / `idea` / `other`; `submit --note` carries extra context (product name, repo, feed quirks). Submissions feed the same review queue as the [web submit form](https://releases.sh/submit).
137
66
 
138
- ### MCP
67
+ ### MCP & Claude Code
139
68
 
140
- Point Claude Code (or any MCP-compatible agent) at the hosted MCP server:
69
+ Point any MCP-compatible agent at the hosted server:
141
70
 
142
71
  ```bash
143
72
  npx mcp-remote https://mcp.releases.sh/mcp
144
73
  ```
145
74
 
146
- Or run a local stdio bridge that proxies the same tools to `api.releases.sh`:
147
-
148
- ```bash
149
- releases admin mcp serve
150
- ```
151
-
152
- ### Claude Code plugins
153
-
154
- This repo is a Claude Code marketplace named `releases` that publishes two plugins. Add the marketplace once, then install whichever surfaces you want:
75
+ This repo is also a Claude Code marketplace with two plugins `releases` (reader: hosted MCP tools, a `/releases` lookup command, and auto-trigger skills) and `releases-admin` (source onboarding + maintenance; needs admin access):
155
76
 
156
77
  ```bash
157
78
  /plugin marketplace add buildinternet/releases-cli
158
-
159
- # Reader surface — search and look up releases:
160
- /plugin install releases@releases
161
-
162
- # Admin surface — onboard and maintain sources (requires admin API access):
163
- /plugin install releases-admin@releases
164
- ```
165
-
166
- Or point at a local clone for development:
167
-
168
- ```bash
169
- claude --plugin-dir .
170
- ```
171
-
172
- **`releases` (reader)** — for anyone querying the registry:
173
-
174
- - **Hosted MCP connection** to `mcp.releases.sh` — search, lookup, and changelog slicing tools.
175
- - **`/releases <product> [query]`** command for manual lookups.
176
- - **Auto-trigger skills:**
177
- - `releases-mcp` — activates on questions about releases, changelogs, or breaking changes ("what's new in Next.js 15?").
178
- - `releases-cli` — activates when a user mentions or runs the `releases` CLI.
179
- - `analyzing-releases` — competitive intel across multiple companies.
180
- - `finding-changelogs` — discovering and evaluating changelog URLs.
181
-
182
- **`releases-admin`** — for maintainers running their own registry or contributing back:
183
-
184
- - **Agents** — `discovery` (finds and onboards sources) and `worker` (executes fetches).
185
- - **Auto-trigger skills:**
186
- - `managing-sources` — CRUD on sources, ignored/blocked URLs, validation.
187
- - `parsing-changelogs` — fetch and parse pipeline reference.
188
- - `classify-media-relevance` — release-image classification helper.
189
- - `seeding-playbooks` — bulk playbook authoring across orgs.
190
-
191
- > Claude Code plugins install atomically — there is no Claude Code–native flow for grabbing a single skill without the rest of the plugin. See the next section for an agent-neutral install path.
192
-
193
- ### Standalone skills (any agent)
194
-
195
- The bundled skills are also available as a standalone package. The fastest way to install them is via the CLI:
196
-
197
- ```bash
198
- releases skills install # detected agent, current project
199
- releases skills install --global # user-wide instead of project
200
- releases skills install --agent cursor # override detection
201
- releases skills install releases-mcp # just the user-facing lookup skill
79
+ /plugin install releases@releases # reader
80
+ /plugin install releases-admin@releases # admin
202
81
  ```
203
82
 
204
- This is a thin wrapper around the [`skills`](https://github.com/vercel-labs/skills) CLI from the open agent-skills ecosystem (`vercel-labs/skills`), which auto-detects ~50 supported agents (Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Windsurf, GitHub Copilot, …) and writes to the right per-agent skills directory. If you'd rather skip the `releases` CLI entirely, the underlying command is:
83
+ Or install just the skills into any agent (Cursor, Codex, Gemini CLI, Windsurf, …):
205
84
 
206
85
  ```bash
207
- npx skills add buildinternet/releases-cli
86
+ releases skills install # or, without the CLI: npx skills add buildinternet/releases-cli
208
87
  ```
209
88
 
210
- Use this path when you only want the skill behavior (auto-triggering on release/CLI questions) without also registering the hosted MCP connection, agents, and `/releases` command that the plugin provides. Skills are symlinked by default, so re-running `releases skills install` (or `npx skills update releases-cli`) refreshes everything atomically.
211
-
212
89
  ## Authentication
213
90
 
214
- Most commands are reader-only and need no auth. The easiest way to get a personal API key is to sign in through your browser — no token to copy or paste:
91
+ Search and browse need no auth. Signing in is what powers the personal touches — **following orgs/products and your customized feed** — and mints a personal **read-only** key (it can't write or administer anything; it just identifies you, and unlocks higher rate limits as those land). The easiest way in is your browser — nothing to copy or paste:
215
92
 
216
93
  ```bash
217
94
  releases login # opens your browser to approve, then saves the key
218
95
  releases login --no-browser # print the URL + code to open yourself (headless / SSH)
219
96
  ```
220
97
 
221
- This uses the OAuth 2.0 Device Authorization Grant (RFC 8628): the CLI shows a short code, you approve it at [releases.sh/device](https://releases.sh/device) in a signed-in browser, and a **read-only** key is minted and saved to `~/.releases/credentials`. Sign up / sign in to the web app first if you haven't. A read-only key is all that's self-serve today; write/admin keys are closed beta (see above).
222
-
223
- ### Managing keys
98
+ This uses the OAuth 2.0 Device Authorization Grant (RFC 8628): approve a short code at [releases.sh/device](https://releases.sh/device) in a signed-in browser, and a read-only key is saved to `~/.releases/credentials` (`0600`). Manage keys with `releases keys list` / `create` / `revoke`.
224
99
 
225
- List, create, and revoke your personal API keys without leaving the terminal:
100
+ Already issued a token (e.g. a write/admin key during the closed beta)? Store it without the browser flow via `releases auth login` (interactive, `--token <token>`, or `--token -` for stdin); it's verified before being saved. `releases auth status` shows the current state (`whoami` is an alias). `RELEASES_API_KEY` in the environment overrides any stored credential — handy for CI.
226
101
 
227
- ```bash
228
- releases keys list # your keys (id, scope, prefix, created, expiry)
229
- releases keys create --name "ci-bot" # mints a read-only key, shown once
230
- releases keys create --name "ci-bot" --expires-in-days 90
231
- releases keys revoke <id> # delete a key (confirm, or pass --yes)
232
- ```
233
-
234
- Keys created here are **read-only** (write/admin are not self-serve). The created key string is shown exactly once — store it then. These commands reuse the session from `releases login`, re-prompting the browser approval only when it has expired; the session is bound to the API environment it was issued against, so switching `RELEASES_API_URL` re-authenticates rather than reusing a key from another environment.
235
-
236
- ### Storing a token directly
237
-
238
- If you've been issued a token (for example a write/admin key during the closed beta), store it without the browser flow using the `auth` namespace, so you don't need `RELEASES_API_KEY` in your shell every time:
239
-
240
- ```bash
241
- releases auth login # interactive prompt (masked input)
242
- releases auth login --token <token> # pass directly
243
- releases auth login --token - # read from stdin (pipe-friendly)
244
- ```
245
-
246
- The token is verified against `GET /v1/tokens/me` before being saved. If verification fails, nothing is written.
247
-
248
- ```bash
249
- releases auth status # show current auth state
250
- releases auth status --json # machine-readable (authenticated, source, scopes, …)
251
- releases auth status --verify # re-check the token against the API live
252
- releases auth token # print the raw token (for scripts)
253
- releases auth logout # remove the stored token
254
- ```
255
-
256
- `whoami` is an alias for `auth status`.
102
+ ## Environment
257
103
 
258
- **Credential precedence:** if `RELEASES_API_KEY` is set in the environment it takes priority over any stored credential — useful for CI or per-command overrides.
104
+ Reader access requires nothing. Useful overrides:
259
105
 
260
- **Storage:** credentials are written to `~/.releases/credentials` with `0600` permissions (owner read/write, rw-------). The file is JSON and contains the token, name, scopes, the API URL the token was verified against, and a `savedAt` timestamp.
106
+ - `RELEASES_API_KEY` Bearer token for write endpoints; overrides stored credentials.
107
+ - `RELEASES_API_URL` — override the default `https://api.releases.sh` (e.g. staging).
108
+ - `RELEASES_TELEMETRY_DISABLED=1` — opt out of anonymous usage pings (`DO_NOT_TRACK=1` also honored).
261
109
 
262
- ## Environment
110
+ See [`.env.example`](./.env.example) for the full list.
263
111
 
264
- Nothing is required for reader access. For admin operations (closed beta — see above):
265
-
266
- - `RELEASES_API_KEY` — Bearer token for write endpoints. Overrides any stored credential from `releases login` / `releases auth login`. Required for any `releases admin …` command that mutates state if no stored credential is present. Write/admin keys are not self-serve yet; a personal **read-only** key is available via `releases login`.
267
- - `RELEASES_API_URL` — Override the default `https://api.releases.sh` endpoint (useful for staging).
268
- - `RELEASES_TELEMETRY_DISABLED=1` — Opt out of anonymous usage pings. `DO_NOT_TRACK=1` is also honored.
269
- - `RELEASES_DISABLE_SKILL_UPDATE_CHECK=1` — Silence the "skills are behind, run `releases skills install`" stderr nag that fires (at most once per 24h) when the GitHub `skills/` tree has moved since your last install.
270
- - `RELEASES_RUN_DIR` — When set, every `releases admin …` write appends one JSONL line (`{timestamp, command, target, result}`) to `$RELEASES_RUN_DIR/mutations.jsonl` — an audit trail for agent-driven maintenance batches. Unset → no-op. Also the default destination for managed-session traces (`--trace-dir` / `--save` override it). Part of the `~/.releases/work/` maintenance workspace.
112
+ ## Exit codes
271
113
 
272
- Copy `.env.example` to `.env` to configure these locally.
114
+ | Code | Meaning |
115
+ | ----- | ------------------------------------------------------------ |
116
+ | `0` | Success |
117
+ | `1` | Application error (network, API, unexpected state) |
118
+ | `2` | Usage / provider error (bad arguments or upstream rejection) |
119
+ | `130` | Cancellation (SIGINT) |
273
120
 
274
121
  ## Contributing
275
122
 
276
123
  Build, test, and release instructions live in [CONTRIBUTING.md](CONTRIBUTING.md).
277
124
 
278
- ## Exit codes
279
-
280
- | Code | Meaning |
281
- | ----- | -------------------------------------------------------------------------------- |
282
- | `0` | Success — session completed or command finished cleanly |
283
- | `1` | Application error — our-side failure (network, API, unexpected state) |
284
- | `2` | Usage / provider error — bad arguments or upstream provider rejected the request |
285
- | `130` | Cancellation — session was cancelled (mirrors the SIGINT convention) |
286
-
287
- Defined in [`src/cli/commands/fetch-wait.ts`](./src/cli/commands/fetch-wait.ts) (`TerminalSummary.exitCode`).
288
-
289
125
  ## License
290
126
 
291
127
  MIT
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@buildinternet/releases",
3
- "version": "0.61.0",
3
+ "version": "0.62.1",
4
4
  "description": "The changelog & release-notes registry for developers and AI agents",
5
5
  "bin": {
6
6
  "releases": "bin/releases"
@@ -13,11 +13,11 @@
13
13
  "README.md"
14
14
  ],
15
15
  "optionalDependencies": {
16
- "@buildinternet/releases-darwin-arm64": "0.61.0",
17
- "@buildinternet/releases-darwin-x64": "0.61.0",
18
- "@buildinternet/releases-linux-x64": "0.61.0",
19
- "@buildinternet/releases-linux-arm64": "0.61.0",
20
- "@buildinternet/releases-windows-x64": "0.61.0"
16
+ "@buildinternet/releases-darwin-arm64": "0.62.1",
17
+ "@buildinternet/releases-darwin-x64": "0.62.1",
18
+ "@buildinternet/releases-linux-x64": "0.62.1",
19
+ "@buildinternet/releases-linux-arm64": "0.62.1",
20
+ "@buildinternet/releases-windows-x64": "0.62.1"
21
21
  },
22
22
  "keywords": [
23
23
  "changelog",