fix(ci): use --output-dir instead of removed --artifacts-dir napi flag#51
Merged
Conversation
@napi-rs/cli v3 renamed the artifacts-collection flag from
--artifacts-dir to --output-dir (also accepts -o / -d). The
build-native.yml publish job still passed --artifacts-dir, so the
"Move artifacts to platform packages" step failed with
"Unsupported option name" on the cachekit-core-ts-v0.1.1 tag push
(run id 24957357035), blocking publication of all 5 platform
packages plus the main core-ts package.
Verified against napi artifacts --help in @napi-rs/cli@3.5.1
locally:
--output-dir,-o,-d #0 Path to the folder where all built
.node files put, same as --output-dir
of build command
No other flag deprecations affect the publish step. The download
target directory (packages/cachekit-core-ts/artifacts) is unchanged.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe build-native.yml workflow is updated to use the renamed ChangesN-API CLI Compatibility
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
4 tasks
27Bslash6
added a commit
that referenced
this pull request
May 17, 2026
…2 release (#52) ## Summary Two real documentation fixes that double as the trigger commit for the 0.1.2 recovery release. ### `packages/cachekit/README.md` - `Requirements: Node.js 18+` was stale. PR #47 bumped `engines.node` to `>=22.0.0` across all packages. README now matches: `Node.js 22+`. - Added a short version-history note explaining the `0.1.0 → 0.1.2` jump on npm so consumers don't think 0.1.1 is missing or yanked. ### `packages/cachekit-core-ts/README.md` (new) Every npm-published package should have a README. This one didn't. Added a minimal one covering: - What the package is and that consumers shouldn't install it directly - The 5 prebuilt platform packages and how `optionalDependencies` selects one - A summary of the public N-API surface - The same 0.1.0 → 0.1.2 version note ## Why this is the bootstrap commit for 0.1.2 The commit touches both `packages/cachekit/` and `packages/cachekit-core-ts/` paths so release-please picks both packages up for a coordinated release. The `Release-As: 0.1.2` trailer skips 0.1.1 (which exists as a git tag but never reached npm) and forces release-please to propose 0.1.2 directly. Type is `docs:` because that's what the changes honestly are — no code behavior changes. The `Release-As:` trailer is what triggers the release, not the type. ## What happens after this merges 1. release-please.yml fires on push to main 2. release-please scans commits since the last published manifest, sees the `Release-As: 0.1.2` trailer and the path touches → opens a release PR titled `chore: release main` proposing 0.1.2 for both packages 3. Merging that release PR cuts tags `cachekit-v0.1.2` and `cachekit-core-ts-v0.1.2` 4. `release-please.yml publish-cachekit` runs (auth fix from PR #45 is in place) → publishes `@cachekit-io/cachekit@0.1.2` 5. The core-ts tag triggers `build-native.yml` → publishes `@cachekit-io/cachekit-core-ts@0.1.2` + creates all 5 platform packages on npm (napi flag fix from PR #51 is in place) After step 5, all 7 packages exist on npm — at which point you can: 6. Configure trusted publishers on npmjs.com for each 7. Take PR #50 out of draft and merge it 8. Delete the `NPM_TOKEN` repo secret after the next OIDC-based release confirms the loop ## Fallback if release-please ignores `Release-As:` on a `docs:` commit If release-please's defaults don't pick up `Release-As:` from a non-releasing commit type, the fallback is to: - Bump both `package.json` files to 0.1.2 directly - Update `.release-please-manifest.json` to 0.1.2 for both packages - Manually create and push the tags I'd open that as a follow-up PR if needed — keeping the doc-fix and the release-trigger separate. ## Test plan - [x] Local validation via prek (no hooks affected by markdown-only changes) - [ ] CI green on this PR - [ ] After merge: confirm release-please opens a 0.1.2 PR within a few minutes - [ ] Merge the release PR and watch both publish workflows go green <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added comprehensive documentation for the native binding package, including installation guidance and platform support details * Updated minimum Node.js version requirement to 22+ * Clarified version and release information <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/cachekit-io/cachekit-ts/pull/52?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->
6 tasks
27Bslash6
added a commit
that referenced
this pull request
May 17, 2026
## Summary Manually applies what release-please would have done if the docs-only trigger commit in #52 had been a "user-facing" type. Release-please skips `docs`/`chore`/`ci`/etc. commits even when `Release-As:` is present — `Release-As:` overrides the *version*, not the release-trigger *gate*. Rather than fake a `fix:` commit (which would have been dishonest, per the feedback on #52's earlier draft), this PR bypasses release-please entirely for the one-time recovery. Future releases use the normal release-please flow. ## What changes | File | Change | |---|---| | `.release-please-manifest.json` | Both packages bumped to `0.1.2` so release-please future runs treat 0.1.2 as the last released state | | `packages/cachekit/package.json` | `version: 0.1.1 → 0.1.2` | | `packages/cachekit-core-ts/package.json` | `version: 0.1.1 → 0.1.2` | | `packages/cachekit/CHANGELOG.md` | New `## [0.1.2]` section explaining the 0.1.1 → 0.1.2 history | | `packages/cachekit-core-ts/CHANGELOG.md` | Same | ## Manual steps after this merges 1. Tag the merge commit and push: ```bash git checkout main && git pull git tag cachekit-v0.1.2 -m "@cachekit-io/cachekit 0.1.2" git tag cachekit-core-ts-v0.1.2 -m "@cachekit-io/cachekit-core-ts 0.1.2" git push origin cachekit-v0.1.2 cachekit-core-ts-v0.1.2 ``` 2. The `cachekit-core-ts-v0.1.2` tag triggers `build-native.yml` → publishes `@cachekit-io/cachekit-core-ts@0.1.2` + creates all 5 platform packages on npm (napi flag fix from #51 is in place). 3. `workflow_dispatch release-please.yml` with `force_release: true` → publishes `@cachekit-io/cachekit@0.1.2`. The release-please job inside will skip (no user-facing commits since 0.1.1), but the `publish-cachekit` job has `force_release == 'true'` as a fire condition and will check out `github.sha` (main HEAD, now 0.1.2) and publish. 4. Verify all 7 packages exist on npm: ```bash for pkg in @cachekit-io/cachekit @cachekit-io/cachekit-core-ts \ @cachekit-io/cachekit-core-ts-linux-x64-gnu \ @cachekit-io/cachekit-core-ts-linux-arm64-gnu \ @cachekit-io/cachekit-core-ts-darwin-x64 \ @cachekit-io/cachekit-core-ts-darwin-arm64 \ @cachekit-io/cachekit-core-ts-win32-x64-msvc; do echo "$pkg: $(npm view "$pkg" version 2>&1)" done ``` 5. Configure trusted publishers on npmjs.com for each of the 7 packages. 6. Take #50 out of draft and merge it. Next release uses OIDC; no `NPM_TOKEN` needed. 7. Delete the `NPM_TOKEN` repo secret. ## Why this isn't tagged by release-please Release-please reads the manifest to know what was last released and proposes the next version from commit history. Once the manifest claims 0.1.2 is already released, release-please will look for commits *after* this PR for the next release. No release PR will be generated for 0.1.2 — that's the whole point of the manual bootstrap. ## Test plan - [x] `pnpm install` confirms lockfile already in sync (workspace deps use `workspace:*`) - [x] CI green on this PR - [ ] After merge: manually tag + push (step 1 above) - [ ] Verify `build-native.yml` run on the tag succeeds end-to-end (including the previously-broken artifact-move step) - [ ] Verify `workflow_dispatch` release-please publish-cachekit succeeds - [ ] Verify all 7 packages on npm at 0.1.2 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **Chores** * Released version 0.1.2 for cachekit and cachekit-core-ts packages. * Updated minimum Node.js requirement to version 22+. * **Documentation** * Added documentation covering platform packages and N-API surface. * Updated changelog entries with release details and version jump explanation. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/cachekit-io/cachekit-ts/pull/53?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->
](https://app.coderabbit.ai/change-stack/cachekit-io/cachekit-ts/pull/52?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack){kind=link}
](https://app.coderabbit.ai/change-stack/cachekit-io/cachekit-ts/pull/53?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack){kind=link}
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The `build-native.yml` publish step has been broken since the @napi-rs/cli v3 upgrade. The `Move artifacts to platform packages` step calls:
```yaml
npx napi artifacts --artifacts-dir artifacts
```
@napi-rs/cli v3 renamed that flag to `--output-dir` (also accepts `-o` / `-d`). The old flag name was removed entirely — passing it now produces:
```
Unsupported option name ("--artifacts-dir").
```
This silently broke publication of the 5 native platform packages and the main `@cachekit-io/cachekit-core-ts` package. The `cachekit-core-ts-v0.1.1` tag (pushed 2026-04-26) attempted to publish via run `24957357035` and failed at this step, which is why npm still only has `cachekit-core-ts@0.1.0` and zero platform packages.
Verification
Ran `napi artifacts --help` against @napi-rs/cli@3.5.1 locally (the exact version pinned in `packages/cachekit-core-ts/package.json`):
```
--output-dir,-o,-d #0 Path to the folder where all built .node
files put, same as --output-dir of build command
```
No other flag changes affect the publish step. The download target directory (`packages/cachekit-core-ts/artifacts`) is unchanged.
Why this matters now
This is step 1 of the bootstrap path for #50 (OIDC trusted publishing). The plan agreed with @27Bslash6:
Test plan
Summary by CodeRabbit