Closed
Conversation
Add the initial Rust project structure for the new ever router, including the reviewed implementation spec, command skeletons, manifest model, catalog data, and resolver/exec modules as the base for phased implementation.
Implement manifest-first product resolution with PATH fallback and auto-registration, expand the built-in product catalog, and turn ever install <product> into a real npm-first registration flow instead of a placeholder.
Replace the old TypeScript CLI package entry with a thin npm wrapper around the native router binary and update the package metadata and README to reflect the new Rust-based router design.
…ipt runtime Introduce ~/.ever/config.toml support for router diagnostics and config initialization, improve doctor/config behavior, and remove the obsolete TypeScript entrypoint and build files now that the package is centered on the Rust router architecture.
…ilt-ins Replace generic CLI parsing with router-controlled command parsing, improve help output, and add npm-first uninstall and update behavior so the root router command set behaves more like the approved spec.
Prove the Rust router against a real product CLI by installing ever-works-cli, registering it in the manifest, surfacing it in doctor, and forwarding ever works --help through the new routing flow.
Run the npm-first update and uninstall paths end to end, populate installed package versions in the manifest, and confirm the router can keep manifest state in sync with real product CLI lifecycle changes.
…ecycle Store richer manifest metadata for installed products, normalize timestamps, and verify the end-to-end install, route, doctor, update, and uninstall flow against ever-works-cli.
Add a first GitHub Actions matrix for the Rust router that builds and uploads native release artifacts for Linux, macOS, and Windows without introducing publish automation yet.
…router Align the main package and wrapper with the planned native distribution model by adding optional platform package dependencies, installed-binary resolution, and scaffold package directories for each supported target. Align the main package and wrapper with the planned native distribution model by adding optional platform package dependencies, installed-binary resolution, and scaffold package directories for each supported target
Update the native build workflow to assemble and upload platform package directories instead of loose binaries, so CI outputs line up with the planned npm distribution structure.
Extend the Rust binary build workflow to cover the full current platform package matrix and add Linux musl setup so CI artifacts align with the planned npm distribution targets.
Introduce reusable packaging scripts for version sync and platform artifact preparation, align the native build workflow with those scripts, and add publish-ready metadata to the main and platform npm packages.
Add a manual GitHub Actions workflow that builds and publishes the platform-specific native packages first, then publishes the main ever-cli package once the platform artifacts are available.
Add the missing ARM64 GNU Linux cross-linker setup in CI, select the musl binary on musl-based Linux systems, and tighten packaging safety by pinning the release tool version and making license copying conditional.
Add the missing ARM64 GNU Linux cross-linker setup to the publish workflow, clean broken local links in the implementation spec, make manifest loading/saving more resilient, and improve npm-not-found error handling for the router.
Add an npm publish prerequisite check for @ever-co scope access, make the publish workflow fail early with a clearer auth/scope error, rewrite the README around the current Rust/native packaging flow, and replace the stale CircleCI release config with a build-validation pipeline.
Summary by CodeRabbit
WalkthroughConsolidated CI: CircleCI moved to v2.1 with a single Rust+Node build job and Cargo caching; GitHub Actions gained a preflight publish job that runs a new npm prerequisite checker; README and package.json updated to reflect Rust-native runtime, altered publishing flow, and the new check script. Changes
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub Actions
participant Runner as Job Runner
participant FS as Repo (npm/cli-*)
participant NPM as npm Registry
GH->>Runner: start preflight-publish job
Runner->>Runner: run `node ./scripts/check-npm-publish-prereqs.js`
Runner->>NPM: npm whoami
NPM-->>Runner: username / auth error
Runner->>NPM: npm access ls-packages `@ever-co` --json
NPM-->>Runner: scope package list
Runner->>FS: scan `npm/cli-*` for package.json names
Runner-->>GH: exit success or fail
alt success
GH->>Runner: start publish-platform job(s)
Runner->>NPM: npm publish (per platform)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR wires in a new
Confidence Score: 4/5Hold for the read-only token false-pass issue in the preflight script before merging. Two P1 findings in the new preflight script: the deprecated scripts/check-npm-publish-prereqs.js — deprecated API call and missing read-write access-level validation.
|
| Filename | Overview |
|---|---|
| scripts/check-npm-publish-prereqs.js | New preflight script to verify npm auth and scope access; uses the deprecated npm access ls-packages subcommand and does not validate write access level, meaning a read-only token passes the gate. |
| .github/workflows/publish-npm-packages.yml | Adds preflight-publish job that gates all platform publishes; workflow structure is correct but inherits the preflight script's access-level gap. |
| .circleci/config.yml | Migrated from old TypeScript npm-publish pipeline to Rust build-only verification; node_modules cache is restored/saved without a corresponding npm install step. |
| package.json | Adds check:publish-prereqs convenience script; no issues. |
| README.md | Documentation updated to reflect new Rust router architecture; old npm-publish and badge sections removed. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A([workflow_dispatch]) --> B[preflight-publish]
B -->|npm whoami| C{Auth OK?}
C -->|No| D[Fail: NPM_TOKEN missing/invalid]
C -->|Yes| E{npm access ls-packages}
E -->|Error| F[Fail: no scope access]
E -->|OK| G[loadPlatformPackages from npm/cli-*/package.json]
G --> H{packages in scope?}
H -->|None| I[Warn: first publish OK]
H -->|Found| J[Log existing packages]
J --> K([publish-platform matrix])
I --> K
K --> L[Build Rust binary per target]
L --> M[prepare-platform-package.js]
M --> N[npm publish dist/artifact]
N --> O([publish-main])
O --> P[npm publish root package]
Reviews (1): Last reviewed commit: "docs(readme): remove merge leftovers and..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.circleci/config.yml:
- Around line 14-17: The CircleCI job config sets up a node cache (restore_cache
/ save_cache keys that reference node_modules) but never runs dependency
installation; either remove the node cache sections (the restore_cache and
save_cache steps that reference ever-cli-node-v1-... and node_modules) or add an
explicit dependency install step (e.g., run npm install or yarn install) before
caching so node_modules is actually populated; update the workflow to
consistently use one approach and remove the unused cache entries if you opt to
keep the scripts dependency-free.
In @.github/workflows/publish-npm-packages.yml:
- Around line 24-27: The workflow sets NODE_AUTH_TOKEN but the script
scripts/check-npm-publish-prereqs.js prints an error mentioning NPM_TOKEN which
is misleading; update the script's error message (in the function or block that
runs npm whoami / checks auth) to reference NODE_AUTH_TOKEN (and optionally
NPM_TOKEN) and explain that setup-node configures auth via NODE_AUTH_TOKEN so
the CLI uses .npmrc, ensuring the error text accurately reflects the env var(s)
the workflow may provide.
In `@scripts/check-npm-publish-prereqs.js`:
- Around line 28-38: The file operations in loadPlatformPackages can throw raw
errors when the npm directory or a cli-*/package.json is missing or malformed;
wrap the body of loadPlatformPackages in a try/catch that catches any error, and
call fail() with a clear, descriptive message that includes the failing path(s)
(use npmDir and packageJsonPath in the message) and the original error.message
so CI output is actionable; ensure the function still returns or rethrows
appropriately after calling fail().
- Around line 50-59: The code parses npm access output into accessiblePackages
but never checks the access level values; update the try block that calls
run('npm', ['access', 'ls-packages', scope, '--json']) and populates
accessiblePackages to inspect the parsed object for "read-write" values (rather
than just presence) and ensure the npm token has write permission for the
relevant packages; if no package under accessiblePackages has "read-write"
access, call fail(...) (the same fail function used now) with a clear error
message about missing write access for the scope, and include the original error
or the parsed output in the log to aid debugging (referencing
accessiblePackages, run, and fail to locate the change).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4a16a353-8201-474e-bf90-d23cb0226da3
📒 Files selected for processing (5)
.circleci/config.yml.github/workflows/publish-npm-packages.ymlREADME.mdpackage.jsonscripts/check-npm-publish-prereqs.js
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@scripts/check-npm-publish-prereqs.js`:
- Line 62: The call to run currently uses the undocumented hyphenated npm
command 'list-packages'; update the argument list passed to run (the call to run
in scripts/check-npm-publish-prereqs.js) to use the documented space-separated
form by replacing the 'access', 'list-packages', ... args with 'access', 'list',
'packages', ... (preserve scope and '--json'); ensure this change is applied
where run('npm', [...]) is invoked so npm receives "access list packages"
instead of "access list-packages".
- Around line 74-94: When writablePackages.length === 0 the script must still
verify the token can publish org-scoped public packages; add a check inside the
else branch after the "No platform packages..." log to call a new helper (e.g.,
verifyOrgOrTeamPublishAccess(token) or ensurePublishAccessForOrganization())
that queries the npm access/org permissions for the token (or attempts a
non-destructive org publish permission check) and fail() if that check indicates
no publish rights; reference writablePackages, accessiblePackages and fail to
locate where to add the verification and ensure the helper returns a boolean or
throws so the script exits with an error when publish rights are absent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 64ba24fa-5adb-44f2-967e-5c03fba5748c
📒 Files selected for processing (2)
.circleci/config.ymlscripts/check-npm-publish-prereqs.js
Comment on lines
+74
to
+94
| const writablePackages = platformPackages.filter( | ||
| (pkg) => Object.hasOwn(accessiblePackages, pkg) && accessiblePackages[pkg] === 'read-write', | ||
| ); | ||
| const readOnlyPackages = platformPackages.filter( | ||
| (pkg) => Object.hasOwn(accessiblePackages, pkg) && accessiblePackages[pkg] !== 'read-write', | ||
| ); | ||
|
|
||
| if (readOnlyPackages.length > 0) { | ||
| fail( | ||
| `The npm token only has read-only access for: ${readOnlyPackages.join( | ||
| ', ', | ||
| )}. Publish requires read-write access.`, | ||
| ); | ||
| } | ||
|
|
||
| if (writablePackages.length > 0) { | ||
| console.log(`Existing writable platform packages in scope: ${writablePackages.join(', ')}`); | ||
| } else { | ||
| console.log( | ||
| 'No platform packages are currently visible in the scope. That is acceptable for a first publish as long as the token has organization publish access.', | ||
| ); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n scripts/check-npm-publish-prereqs.jsRepository: ever-co/ever-cli
Length of output: 3567
🏁 Script executed:
cat -n .github/workflows/publish-npm-packages.ymlRepository: ever-co/ever-cli
Length of output: 5780
🌐 Web query:
npm access list-packages behavior public packages documentation
💡 Result:
npm access ls-packages (shown in some docs as npm access list packages) is not a “list all public packages” or “list all packages under a scope” command.
- It lists the packages a user / org scope / team can access and their access level, but it explicitly omits “read-only public packages” so it won’t dump the entire public registry (and it also won’t show packages where the only access is the global, anonymous “read-only because it’s public” access). [1]
- Related visibility context: unscoped packages are always public, and scoped packages can be public or private. Public packages are viewable/downloadable by everyone, while write access is limited. [1][2][3]
Docs: see the npm access command page and its ls-packages description (including the “except for read-only public packages” note). [1]
Sources
[1] npm Docs – npm-access (ls-packages behavior note) (docs.npmjs.com)
[2] npm Docs – About public packages (docs.npmjs.com)
[3] npm Docs – Package scope, access level, and visibility (docs.npmjs.com)
Citations:
- 1: https://docs.npmjs.com/cli/v9/commands/npm-access/
- 2: https://docs.npmjs.com/about-public-packages/
- 3: https://docs.npmjs.com/package-scope-access-level-and-visibility/
🌐 Web query:
npm v6 access list-packages read-only packages output
💡 Result:
In npm v6, npm access ls-packages [<user>|<scope>|<scope:team>] lists the packages that the specified user/team/scope can access and includes the access level—except it intentionally omits “read-only public packages” (so it doesn’t dump the whole public registry). [1]
Output format: the npm CLI prints the result as JSON (a map of package name → permission such as read-only / read-write). [2]
Example shape:
{
"@yourscope/pkg-a": "read-write",
"@yourscope/pkg-b": "read-only"
}Sources: [1] [2]
Add verification for write access to prevent false-pass on existing public packages.
The npm access list-packages command omits read-only public packages from its output, making writablePackages.length === 0 ambiguous. Since packages are published with --access public, a token with only read access to existing public packages will not appear in the listing. The script would incorrectly pass the preflight check but fail during actual publish.
Add a separate check to verify that the token has organization or team publish permissions before allowing the script to complete successfully in the zero-match case.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@scripts/check-npm-publish-prereqs.js` around lines 74 - 94, When
writablePackages.length === 0 the script must still verify the token can publish
org-scoped public packages; add a check inside the else branch after the "No
platform packages..." log to call a new helper (e.g.,
verifyOrgOrTeamPublishAccess(token) or ensurePublishAccessForOrganization())
that queries the npm access/org permissions for the token (or attempts a
non-destructive org publish permission check) and fail() if that check indicates
no publish rights; reference writablePackages, accessiblePackages and fail to
locate where to add the verification and ensure the helper returns a boolean or
throws so the script exits with an error when publish rights are absent.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
scripts/check-npm-publish-prereqs.js (1)
89-94:⚠️ Potential issue | 🟠 MajorPreflight can still false-pass when no writable packages are listed.
At Line 91-94, the script exits successfully without a definitive publish-rights check. This can allow preflight to pass and fail later during publish if the token lacks org-level create/publish permission.
For npm CLI (current stable), does `npm access list packages <scope> --json` definitively prove a token can publish new scoped public packages, or can it omit cases where publish still fails? Please provide official npm docs references.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/check-npm-publish-prereqs.js` around lines 89 - 94, The script currently treats an empty writablePackages array as acceptable and exits successfully; instead add an explicit org-level publish permission check when writablePackages.length === 0: inside the same control flow around writablePackages (the variable in scripts/check-npm-publish-prereqs.js and the surrounding function that evaluates publish prereqs), perform a definitive check for create/publish rights — either by invoking a reliable npm permission check (e.g., call the npm registry access API for the org or attempt a safe npm publish verification such as an npm publish --dry-run to a uniquely-named temporary package using the provided token) and if that check fails or cannot confirm create/publish rights, exit non-zero and log a clear error; ensure the new check runs only when writablePackages is empty and make the error path explicit so preflight cannot false-pass.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@scripts/check-npm-publish-prereqs.js`:
- Around line 60-79: The parsed npm access result (accessiblePackages) may be
null or not an object, causing Object.hasOwn calls in
writablePackages/readOnlyPackages to throw; after calling run(...) and
JSON.parse(...) in the try block, validate that accessiblePackages is a non-null
object (e.g., typeof accessiblePackages === 'object' && accessiblePackages !==
null && !Array.isArray(accessiblePackages')) and if the shape is invalid call
fail(...) with a clear message about unexpected npm access JSON for the scope;
update the try/catch around run/JSON.parse and reference the same symbols
(accessiblePackages, run, fail, loadPlatformPackages, writablePackages,
readOnlyPackages) so later filters safely assume an object map.
---
Duplicate comments:
In `@scripts/check-npm-publish-prereqs.js`:
- Around line 89-94: The script currently treats an empty writablePackages array
as acceptable and exits successfully; instead add an explicit org-level publish
permission check when writablePackages.length === 0: inside the same control
flow around writablePackages (the variable in
scripts/check-npm-publish-prereqs.js and the surrounding function that evaluates
publish prereqs), perform a definitive check for create/publish rights — either
by invoking a reliable npm permission check (e.g., call the npm registry access
API for the org or attempt a safe npm publish verification such as an npm
publish --dry-run to a uniquely-named temporary package using the provided
token) and if that check fails or cannot confirm create/publish rights, exit
non-zero and log a clear error; ensure the new check runs only when
writablePackages is empty and make the error path explicit so preflight cannot
false-pass.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c1230708-8dbe-4cfd-a45e-61f6363ef589
📒 Files selected for processing (1)
scripts/check-npm-publish-prereqs.js
Comment on lines
+60
to
+79
| let accessiblePackages; | ||
| try { | ||
| const output = run('npm', ['access', 'list', 'packages', scope, '--json']); | ||
| accessiblePackages = output ? JSON.parse(output) : {}; | ||
| } catch (error) { | ||
| fail( | ||
| `Unable to verify publish access for ${scope}. Ensure the npm token belongs to a user with write access to the ${scope} organization.`, | ||
| error, | ||
| ); | ||
| } | ||
|
|
||
| const platformPackages = loadPlatformPackages(); | ||
| console.log(`Verified npm scope access for ${scope}.`); | ||
|
|
||
| const writablePackages = platformPackages.filter( | ||
| (pkg) => Object.hasOwn(accessiblePackages, pkg) && accessiblePackages[pkg] === 'read-write', | ||
| ); | ||
| const readOnlyPackages = platformPackages.filter( | ||
| (pkg) => Object.hasOwn(accessiblePackages, pkg) && accessiblePackages[pkg] !== 'read-write', | ||
| ); |
There was a problem hiding this comment.
Validate parsed access map shape before Object.hasOwn.
At Line 63, parsed JSON is not validated. If npm returns an unexpected JSON type (e.g., null), Line 75/Line 78 can throw a raw TypeError instead of using fail().
♻️ Suggested fix
let accessiblePackages;
try {
const output = run('npm', ['access', 'list', 'packages', scope, '--json']);
- accessiblePackages = output ? JSON.parse(output) : {};
+ const parsed = output ? JSON.parse(output) : {};
+ if (!parsed || typeof parsed !== 'object' || Array.isArray(parsed)) {
+ fail(`Unexpected npm access response format for ${scope}: ${output}`);
+ }
+ accessiblePackages = parsed;
} catch (error) {
fail(
`Unable to verify publish access for ${scope}. Ensure the npm token belongs to a user with write access to the ${scope} organization.`,
error,
);
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@scripts/check-npm-publish-prereqs.js` around lines 60 - 79, The parsed npm
access result (accessiblePackages) may be null or not an object, causing
Object.hasOwn calls in writablePackages/readOnlyPackages to throw; after calling
run(...) and JSON.parse(...) in the try block, validate that accessiblePackages
is a non-null object (e.g., typeof accessiblePackages === 'object' &&
accessiblePackages !== null && !Array.isArray(accessiblePackages')) and if the
shape is invalid call fail(...) with a clear message about unexpected npm access
JSON for the scope; update the try/catch around run/JSON.parse and reference the
same symbols (accessiblePackages, run, fail, loadPlatformPackages,
writablePackages, readOnlyPackages) so later filters safely assume an object
map.
Member
|
@Ntermast you was supposed to make PR on top of LATEST in develop branch, same mistakes again...rebase please!! |
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
2 participants
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.
No description provided.