claude-use 1.2.0 → 1.3.0
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.
- package/README.md +4 -0
- package/dist/cli.cjs +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,5 +1,7 @@
|
|
|
1
1
|
# claude-use
|
|
2
2
|
|
|
3
|
+
[](https://github.com/ExaDev/claude-use) [](https://www.npmjs.com/package/claude-use) [](https://github.com/ExaDev/claude-use/releases/latest) [](https://github.com/ExaDev/claude-use/actions) [](https://github.com/ExaDev/homebrew-claude-use) [](https://github.com/ExaDev/scoop-claude-use)
|
|
4
|
+
|
|
3
5
|
A profile manager and launcher for [Claude Code](https://claude.com/claude-code) that lets one person run multiple logins from one machine while controlling — precisely, and per working directory — what gets shared between them.
|
|
4
6
|
|
|
5
7
|
## The problem
|
|
@@ -561,6 +563,8 @@ Every push to `main` runs [semantic-release](https://github.com/semantic-release
|
|
|
561
563
|
|
|
562
564
|
One accepted quirk worth knowing rather than being surprised by: semantic-release creates the release tag pointing at the commit that already existed (the actual code change being released) *before* running `@semantic-release/git`'s commit step — so the changelog/version-bump commit lands on `main` **after** the tag, not folded into it. Every downstream job below checks out `ref: main` (not the commit that triggered the run) specifically to pick up this post-release state, matching how this org's other semantic-release repos handle the identical quirk.
|
|
563
565
|
|
|
566
|
+
**The six platform build jobs (`build-arm64` through `build-windows-arm64`) also run on every pull request, not only a published release.** Each builds the real SEA binary for its own platform and then directly executes it (`--version`, `--help`) as a genuine smoke test — this is what would have caught, before merge rather than after a real release, an actual regression this project shipped once: a Turbo cache key that didn't distinguish `runner.arch`, letting one architecture's compiled binary silently serve for another (see `.github/actions/setup-and-run/action.yml`'s own comment). On a PR, each build job checks out the PR's own head commit instead of `ref: main`, since there's no post-release state to pick up yet. Publishing itself — npm, GitHub Packages, the GitHub Release, and the Homebrew/Scoop tap updates — stays gated on `needs.semantic-release.outputs.published == 'true'` alone and never runs on a PR, since those all have real, one-way side effects.
|
|
567
|
+
|
|
564
568
|
**Branch/tag protection had to be disabled for this to work.** `main`'s branch-protection ruleset previously required every push go through a reviewed PR, and a separate ruleset blocked tag creation/deletion outright — both only bypassable by the Admin repository role. semantic-release's own git operations run as the workflow's default `GITHUB_TOKEN`, which doesn't hold that role, so both rulesets were disabled (not deleted — the rule definitions are preserved and can be re-enabled with a single API call or via the repo's Rules settings page) rather than routing around them with a separate bypass credential.
|
|
565
569
|
|
|
566
570
|
**The build/publish/verify pipeline below is not a separate tag-triggered workflow run — it's later jobs in this SAME run, gated on `needs: [semantic-release]`.** This project originally tried the opposite: let semantic-release's tag push trigger a second, tag-scoped workflow run, the way `ci.yml` used to be structured before this section was rewritten. That never worked — GitHub Actions never lets a `GITHUB_TOKEN`-authenticated push start a new workflow run, to prevent recursive loops, and (confirmed empirically, since most write-ups only discuss `GITHUB_TOKEN` and imply any other credential is exempt) an SSH deploy key registered on the repository hit the identical restriction. This org's other semantic-release repos (`graphle`, `spot-of-the-day`) never hit this at all, because their own post-release jobs (a Pages redeploy, a Worker deploy) are idempotent and just run unconditionally on every push to `main` — they never need to ask "did a release actually happen." Building five platform binaries, publishing to npm, and updating two external tap repos are not safe to run unconditionally, so this project's `semantic-release` job runs a plain `git describe --exact-match --tags HEAD` right after `npx semantic-release` and exposes the result as job outputs (`published`, `version`, `tag`) — no plugin needed, since it's just a shell check, not a hook into semantic-release's own plugin lifecycle. Every downstream job gates on `needs.semantic-release.outputs.published == 'true'`.
|
package/dist/cli.cjs
CHANGED
|
@@ -221857,7 +221857,7 @@ var categories_default_default = {
|
|
|
221857
221857
|
// package.json
|
|
221858
221858
|
var package_default = {
|
|
221859
221859
|
name: "claude-use",
|
|
221860
|
-
version: "1.
|
|
221860
|
+
version: "1.3.0",
|
|
221861
221861
|
description: "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
|
|
221862
221862
|
license: "Apache-2.0",
|
|
221863
221863
|
author: "Joseph Mearman <joseph@mearman.co.uk>",
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "claude-use",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.3.0",
|
|
4
4
|
"description": "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"author": "Joseph Mearman <joseph@mearman.co.uk>",
|