Skip to content

feat(cli): build an installable npm tarball - #3173

Merged
M4n5ter merged 2 commits into
mainfrom
feat/cli-npm-tarball
Aug 18, 2026
Merged

feat(cli): build an installable npm tarball#3173
M4n5ter merged 2 commits into
mainfrom
feat/cli-npm-tarball

Conversation

@M4n5ter

@M4n5ter M4n5ter commented Aug 17, 2026

Copy link
Copy Markdown
Member
English

Summary

Refs #3166

Builds maka-agent@0.1.0-beta.1 as one installable npm tarball containing the exact production dependency closure, private @maka/* runtime packages, Eval resources, native prebuilds, dependency patches, and license notices. The source workspace remains private; only the generated manifest is publishable.

Publishable artifacts are built from the committed source in an isolated tree after an exact npm ci, so ignored local dependency changes cannot enter the release. A single audited file policy removes third-party tests, fixtures, coverage, TypeScript sources, declarations, and source maps while preserving runtime JavaScript and native assets.

The installed CLI points Eval container mounts at its packaged resource mirror without overriding an explicit user path. Install-time dependency scripts and native compilation are removed from the release snapshot.

Verification

  • npm run release:cli:pack — 14.3 MiB tarball, stable SHA-256 d288fe0e6018f8f420ea865446bf36c7848eda917c80867dc8301c6f71c3d551 across two isolated builds
  • npm run release:cli:smoke — offline empty-cache install; both bins, Eval import, PTY, native file locks, workers, assets, and patches verified
  • npm --workspace maka-agent run test:dist — 265 passed
  • npm run rebuild
  • npm run typecheck
  • npm run check:release
  • npm run format:check
  • npm run lint

Follow-up

The cross-platform CI matrix, real Harbor/Pier cells, and protected OIDC publishing workflow remain separate follow-up PRs.

中文

概要

关联 #3166

maka-agent@0.1.0-beta.1 组装为单一可安装 npm tarball,包含精确生产依赖闭包、私有 @maka/* 运行包、Eval 资源、原生 prebuild、依赖补丁和许可证声明。源码 workspace 继续保持 private,只有生成的最终 manifest 可发布。

可发布产物会从当前提交导出隔离源码树,并在精确执行 npm ci 后构建,因此本机被忽略的依赖修改无法进入发布包。统一且可审查的文件策略会排除第三方测试、fixture、coverage、TypeScript 源文件、类型声明和 source map,同时保留运行时 JavaScript 与原生产物。

安装态 CLI 会将 Eval 容器挂载指向包内资源镜像,同时保留用户显式配置。发布快照不会在用户机器上执行依赖安装脚本或编译原生模块。

验证

  • npm run release:cli:pack — 14.3 MiB,两次隔离构建均得到 SHA-256 d288fe0e6018f8f420ea865446bf36c7848eda917c80867dc8301c6f71c3d551
  • npm run release:cli:smoke — 空 cache 离线安装;验证两个命令、Eval 导入、PTY、原生文件锁、worker、资源和补丁
  • npm --workspace maka-agent run test:dist — 265 项通过
  • npm run rebuild
  • npm run typecheck
  • npm run check:release
  • npm run format:check
  • npm run lint

后续

跨平台 CI 矩阵、真实 Harbor/Pier cell 和受保护的 OIDC 发布 workflow 将在后续 PR 中完成。

AI use

  • No generative tool made a substantive contribution
  • Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex — implementation, tests, packaging analysis, and verification.

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — described under Summary above
  • No

@coderabbitai

coderabbitai Bot commented Aug 17, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Problem solved

This PR creates a publishable maka-agent@0.1.0-beta.1 npm tarball. The tarball includes production dependencies, private @maka/* packages, Eval resources, native prebuilds, patches, and license notices. The CLI uses packaged Eval resources unless the user sets an explicit path.

The build uses an isolated source archive, exact npm ci, a reviewed file policy, and disabled install-time compilation.

Source of truth and solution size

The PR extends the existing workspace and committed source. It does not create a parallel source path. The generated manifest and tarball are release outputs.

The solution is coherent but substantial because it must package a private workspace safely. The release script validates inputs, stages runtime files, removes development artifacts, checks dependency patches and notices, rejects unsafe files, and verifies the final tarball. The smoke test validates offline installation and installed behavior.

Simplification opportunities

No clear deletion is supported by the current summary. The file-policy tests, Eval path tests, packaging checks, notice validation, and smoke tests cover separate release risks. Any simplification should preserve coverage for dependency closure, native assets, package contents, licensing, offline installation, and CLI behavior.

Validation and risks

Reported validation includes:

  • Reproducible 14.3 MiB tarballs with the specified SHA-256.
  • Offline installation and CLI smoke tests.
  • 265 distribution tests.
  • Rebuild, typecheck, release checks, formatting, and linting.
  • File-policy, notice, Eval bundle path, and native asset checks.

Cross-platform CI, real Harbor/Pier cells, and protected OIDC publishing remain follow-up work. Final required-check status is unverified from the available evidence.

Review-relevant risks

  • The PR changes the public npm release artifact, package version, install behavior, and CLI distribution path. Material release or public-contract changes require independent human review under repository policy.
  • The PR controls packaged dependency scripts, native assets, repository-path leakage, and offline installation. Material security changes require independent human review under repository policy.
  • The PR generates and validates third-party license notices, including a version-pinned copyright override. Material licensing changes require independent human review under repository policy.
  • The PR adds release packaging and publishing-related checks. Material governance changes require independent human review under repository policy.

The person performing the merge reviews the final diff. A maintainer makes the final determination.

Walkthrough

The CLI release flow now configures installed Eval assets, generates target-specific notices, builds sanitized release archives, and validates them through offline installation smoke tests.

Changes

CLI runtime setup

Layer / File(s) Summary
Installed Eval bundle configuration
packages/cli/src/eval-bundle-path.ts, packages/cli/src/cli-core.ts, packages/cli/src/__tests__/eval-bundle-path.test.ts
The eval command configures the installed Eval bundle path before loading @maka/eval. Tests cover explicit overrides and missing bundle directories.

Release preparation and packaging

Layer / File(s) Summary
Target notices and release file policies
scripts/generate-third-party-notices.mjs, scripts/release-cli-file-policy.mjs, scripts/release-cli-file-policy.test.mjs
Notice generation now supports desktop and CLI targets. File-policy helpers classify development artifacts and include focused tests.
CLI release assembly and metadata
scripts/release-cli-package.mjs, package.json, .gitignore, packages/cli/package.json, packages/cli/README.md
The release script builds, stages, sanitizes, validates, and packs the CLI. Repository scripts, ignored output, beta metadata, and CLI documentation support the release.

Release validation

Layer / File(s) Summary
Offline package smoke validation
scripts/smoke-release-cli-package.mjs
The smoke test installs the tarball offline and checks CLI commands, native modules, runtime files, and patched dependencies.

Estimated code review effort: 5 (Critical) | ~120 minutes

Merge Risk: 🔵 Low · up to c34d2

The PR adds an installable CLI tarball and packaged Eval resources. The artifact is supported by extensive checks, but the release smoke validation can intermittently fail on PTY output timing or stall during offline installation, so merge is reasonable with explicit owner awareness and follow-up.

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseCommand as npm release command
  participant PackageScript as release-cli-package.mjs
  participant BuildWorkspace as isolated clean build
  participant Tarball as CLI tarball
  participant SmokeTest as smoke-release-cli-package.mjs
  ReleaseCommand->>PackageScript: start CLI release
  PackageScript->>BuildWorkspace: build and audit dependencies
  BuildWorkspace->>PackageScript: return build artifacts
  PackageScript->>Tarball: stage, validate, and pack files
  SmokeTest->>Tarball: install package offline
  SmokeTest->>SmokeTest: validate CLI, native modules, and runtime files
Loading
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Ai Use Disclosure ⚠️ Warning The PR selects generative use and names OpenAI Codex for implementation; commit c34d22c has no valid Generated-by trailer, while 5daeb6b does. Add Generated-by: OpenAI Codex to c34d22c (or the final squash commit), ensure it survives squash or amend, and follow CONTRIBUTING.md's Human ownership and AI attribution section.
✅ Passed checks (4 passed)
Check name Status Explanation
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly and concisely describes the main change: building an installable npm tarball for the CLI.
Description check ✅ Passed The description includes the required summary, verification, AI-use declaration, checklist, behavior change, and relevant follow-up information.
✨ Finishing Touches 💡 1
🛠️ Fix failing CI checks 💡
  • Create stacked PR
  • Commit on current branch
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/cli-npm-tarball

Comment @coderabbitai help to get the list of available commands.

@M4n5ter
M4n5ter marked this pull request as ready for review August 18, 2026 01:13
@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Build reproducible installable npm tarball for Maka CLI

✨ Enhancement 🧪 Tests 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

Grey Divider

AI Description

• Builds a reproducible npm tarball containing the complete CLI production runtime.
• Preserves packaged Eval resources while respecting explicit user bundle paths.
• Validates licenses, release contents, native assets, and offline global installation.
Diagram

graph TD
  A["Committed source"] --> B["Isolated tree"] --> C["Exact npm ci"] --> D["Workspace builds"] --> E["Runtime closure"] -->|"audited policy"| F["Release staging"] --> G["npm tarball"] --> H["Offline install"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Publish each workspace package
  • ➕ Uses npm's standard dependency resolution and package boundaries.
  • ➕ Allows private runtime packages to be versioned and updated independently.
  • ➖ Requires publishing and coordinating every private @maka package.
  • ➖ Cannot guarantee a single self-contained artifact or offline installation.
  • ➖ Expands the public package surface beyond the CLI.
2. Bundle JavaScript with a standard packager
  • ➕ Could reduce package size and simplify the visible dependency tree.
  • ➕ May eliminate much of the custom dependency-copying logic.
  • ➖ Dynamic imports, workers, native modules, and Eval resources require extensive exceptions.
  • ➖ Bundling can alter runtime behavior and obscure dependency patches.
  • ➖ License attribution and native prebuild handling remain separate concerns.

Recommendation: Keep the single audited tarball approach. It best satisfies the explicit requirements for private workspace encapsulation, exact dependency fidelity, packaged Eval resources, native prebuilds, offline installation, and no install-time builds; publishing workspaces or bundling JavaScript would trade away those guarantees.

Files changed (13) +1042 / -14

Enhancement (2) +19 / -0
cli-core.tsConfigure packaged Eval resources before execution +2/-0

Configure packaged Eval resources before execution

• Initializes the installed Eval bundle path before dynamically loading and running the Eval CLI.

packages/cli/src/cli-core.ts

eval-bundle-path.tsDiscover the installed Eval resource mirror +17/-0

Discover the installed Eval resource mirror

• Sets 'MAKA_EVAL_MAKA_BUNDLE_PATH' when the package contains an Eval mirror, without overriding an existing environment value.

packages/cli/src/eval-bundle-path.ts

Tests (3) +216 / -0
eval-bundle-path.test.tsTest installed Eval bundle discovery +35/-0

Test installed Eval bundle discovery

• Verifies packaged Eval resources set the container bundle path while explicit user configuration and source-checkout behavior remain unchanged.

packages/cli/src/tests/eval-bundle-path.test.ts

release-cli-file-policy.test.mjsTest release artifact filtering rules +41/-0

Test release artifact filtering rules

• Covers Windows and POSIX paths, third-party runtime preservation, native assets, and the stricter policy for Maka-owned packages.

scripts/release-cli-file-policy.test.mjs

smoke-release-cli-package.mjsVerify an offline global CLI installation +140/-0

Verify an offline global CLI installation

• Installs the tarball globally using an empty offline cache and exercises both binaries, Eval loading, PTY support, native file locks, workers, resources, and patched dependencies.

scripts/smoke-release-cli-package.mjs

Documentation (1) +26 / -0
README.mdDocument installation and beta requirements +26/-0

Document installation and beta requirements

• Introduces package-facing installation instructions, supported binaries, Node.js requirements, Eval prerequisites, and project links.

packages/cli/README.md

Other (7) +781 / -14
.gitignoreIgnore generated CLI release artifacts +1/-0

Ignore generated CLI release artifacts

• Excludes the CLI release staging directory, tarball, checksum, and inventory outputs from source control.

.gitignore

package-lock.jsonLock the CLI beta package version +1/-1

Lock the CLI beta package version

• Updates the locked 'maka-agent' workspace version to '0.1.0-beta.1', matching the release manifest source.

package-lock.json

package.jsonRegister CLI release and verification commands +5/-1

Register CLI release and verification commands

• Adds commands for CLI notices, tarball creation, and offline smoke testing. Extends release checks with CLI notice drift and file-policy tests.

package.json

package.jsonSet the CLI beta release version +1/-1

Set the CLI beta release version

• Changes the private source workspace version to '0.1.0-beta.1'; publishability remains limited to the generated release manifest.

packages/cli/package.json

generate-third-party-notices.mjsGenerate notices for desktop or CLI closures +38/-11

Generate notices for desktop or CLI closures

• Generalizes notice generation across target workspaces and adds CLI-specific output metadata. Desktop-only asset validation remains scoped to desktop notices.

scripts/generate-third-party-notices.mjs

release-cli-file-policy.mjsDefine audited release file exclusions +38/-0

Define audited release file exclusions

• Centralizes cross-platform rules for removing tests, fixtures, coverage, TypeScript artifacts, declarations, and source maps while retaining runtime assets.

scripts/release-cli-file-policy.mjs

release-cli-package.mjsAssemble and validate the installable CLI tarball +697/-0

Assemble and validate the installable CLI tarball

• Builds from an isolated Git archive after exact 'npm ci', then stages the production dependency closure, private workspaces, Eval resources, native prebuilds, patches, notices, and a publishable manifest. It rejects unsafe or development files, strips reviewed install scripts, validates required runtime content, and emits the tarball, checksum, and file inventory.

scripts/release-cli-package.mjs

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (3)
scripts/generate-third-party-notices.mjs (1)

31-32: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Guard the target lookup against inherited Object.prototype keys.

TARGETS[targetName] resolves inherited members. --target constructor or --target toString returns a truthy value, so the guard on Line 32 does not fire. The script then calls npm ls --workspace undefined and fails with an unrelated message. Use an own-property check.

♻️ Proposed change
-const target = TARGETS[targetName];
-if (!target) throw new Error(`Unsupported notice target: ${targetName}`);
+if (!Object.hasOwn(TARGETS, targetName)) {
+  throw new Error(`Unsupported notice target: ${targetName}`);
+}
+const target = TARGETS[targetName];
scripts/release-cli-package.mjs (1)

273-278: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Extract the pinned undici version into one constant.

The exact version 8.10.0 appears at Line 273 and Line 456. An upgrade must change both places. A single constant removes that coupling.

♻️ Proposed change
+const EVAL_UNDICI_VERSION = '8.10.0';
-  const evalUndici = findDependency(cli, 'undici', '8.10.0');
+  const evalUndici = findDependency(cli, 'undici', EVAL_UNDICI_VERSION);
   if (!evalUndici?.path || !existsSync(evalUndici.path)) {
-    throw new Error('The installed CLI closure does not contain undici@8.10.0');
+    throw new Error(`The installed CLI closure does not contain undici@${EVAL_UNDICI_VERSION}`);
   }
-  const undici = findDependency(cli, 'undici', '8.10.0');
+  const undici = findDependency(cli, 'undici', EVAL_UNDICI_VERSION);

Also applies to: 456-457

scripts/smoke-release-cli-package.mjs (1)

24-39: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Add a timeout to the offline install.

run applies a 30 s timeout, but this execFileSync call has none. If npm install --offline hangs, the smoke test blocks the pipeline with no diagnostic. A bounded timeout produces a clear failure.

♻️ Proposed change
-    npmSpawnOptions({ cwd: root, stdio: 'inherit' }),
+    npmSpawnOptions({ cwd: root, stdio: 'inherit', timeout: 300_000 }),

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 715f1b0b-3733-4875-9c9e-e9d8266d6438

📥 Commits

Reviewing files that changed from the base of the PR and between 5d9ce0d and c34d22c.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (13)
  • .gitignore
  • package.json
  • packages/cli/README.md
  • packages/cli/THIRD_PARTY_NOTICES.txt
  • packages/cli/package.json
  • packages/cli/src/__tests__/eval-bundle-path.test.ts
  • packages/cli/src/cli-core.ts
  • packages/cli/src/eval-bundle-path.ts
  • scripts/generate-third-party-notices.mjs
  • scripts/release-cli-file-policy.mjs
  • scripts/release-cli-file-policy.test.mjs
  • scripts/release-cli-package.mjs
  • scripts/smoke-release-cli-package.mjs

Included review availability: Your plan includes up to 3 reviews per rolling hour; 2 remain after this review.

Comment thread scripts/smoke-release-cli-package.mjs
@qodo-code-review

qodo-code-review Bot commented Aug 18, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Action required

1. Concurrent builds corrupt artifacts ✗ Dismissed 🐞 Bug ☼ Reliability
Description
Fix now: every release invocation recursively deletes and recopies the same packages/cli/release
directory, so overlapping builds can remove or interleave each other's tarball, checksum, and file
manifest. This can leave a failed build or mutually inconsistent release artifacts even though each
isolated build completed correctly.
Code

scripts/release-cli-package.mjs[R166-167]

+    rmSync(releaseRoot, { recursive: true, force: true });
+    cpSync(cleanReleaseRoot, releaseRoot, { recursive: true, preserveTimestamps: true });
Relevance

●●● Strong

PR #1920 explicitly accepted a closely matching concurrent rm-and-rebuild race requiring
serialization.

PR-#1920

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The script defines one fixed release destination, deletes/recreates it during both direct and
isolated builds, and writes all three related artifacts there without synchronization. The cited
past PR demonstrates the same destructive shared-directory race pattern elsewhere in this
repository.

scripts/release-cli-package.mjs[28-29]
scripts/release-cli-package.mjs[108-134]
scripts/release-cli-package.mjs[162-168]
PR-#1920

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Concurrent `release:cli:pack` processes destructively update the same release directory and can produce missing or inconsistent artifacts.

## Issue Context
Keep the isolated per-build working trees, but serialize the final shared-output replacement. Deleting this output path is not possible because it is the command's product, and consolidating existing authority is insufficient because no current component owns cross-process publication; the smallest correction is a release-output lock. This introduces one short-lived lock-file state and its stale-lock/error-handling burden, scoped only to final output publication.

## Fix Focus Areas
- scripts/release-cli-package.mjs[143-171]
- scripts/release-cli-package.mjs[108-109]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. Required peer bundling ignores hoisted destinations 🐞 Bug ≡ Correctness
Description
copyDependencyClosure() only calls addBundledDependency() for required peer edges whose
destination is nested under the consuming package, even though internal and many third-party
dependencies are flattened to top-level stageRoot/node_modules, while transitive non-peer
dependencies such as @maka/code-mode are not considered at all. These packages can therefore be
staged without appearing in the root bundledDependencies, creating an npm-version-sensitive risk
that npm pack omits them and the shipped CLI fails at runtime, although recursive
bundled-dependency behavior and validatePackedFiles() may prevent or expose the issue.
Code

scripts/release-cli-package.mjs[R260-266]

+        if (
+          peerPolicy === 'required' &&
+          parentDestination &&
+          destination === join(parentDestination, 'node_modules', ...dependency.name.split('/'))
+        ) {
+          addBundledDependency(parentDestination, dependency.name, dependency.version);
+        }
Relevance

●● Moderate

No close precedent; packaging semantics are explicitly uncertain and validation may already expose
omissions.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
dependencyDestination() flattens hoisted third-party packages and all internal packages, including
@maka/code-mode, into top-level stageRoot/node_modules, so the required-peer comparison with
join(parentDestination, 'node_modules', ...) cannot match for those dependencies. The generated
root manifest derives its dependencies and bundledDependencies only from the CLI's direct
dependencies, which do not include @maka/code-mode; it is instead reachable through the direct
bundled dependency @maka/runtime, whose own dependencies include it. npm packlist generally
retains named bundled dependencies and may recurse through their dependency trees, so actual
inclusion of this flattened transitive package depends on npm's packing behavior;
validatePackedFiles() should detect an omission by checking staged dependency manifests against
the tarball, but the behavior has not been verified against the actual CI-produced archive.

scripts/release-cli-package.mjs[301-327]
scripts/release-cli-package.mjs[236-268]
scripts/release-cli-package.mjs[236-282]
scripts/release-cli-package.mjs[448-492]
packages/cli/package.json[20-28]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description

`copyDependencyClosure()` only invokes `addBundledDependency()` for required peer-dependency edges whose computed destination is directly below the parent's own `node_modules`. Because `dependencyDestination()` flattens most third-party packages and all internal packages into top-level `stageRoot/node_modules/<name>`, that condition cannot match hoisted required peers; transitive non-peer dependencies such as `@maka/code-mode` are also not added to the root `bundledDependencies`, creating a risk that staged packages are omitted by `npm pack`.

## Issue Context

The release manifest's root `dependencies` and `bundledDependencies` are derived only from the CLI's direct dependencies. `@maka/code-mode` is not a direct CLI dependency but is required through `@maka/runtime`, which is directly bundled; npm may include it by recursively packing a bundled dependency's dependency tree, but that behavior for flattened dependencies is npm-version-sensitive and was not verified against the actual tarball. `validatePackedFiles()` should fail the build if a physically staged dependency manifest is absent from the packed files, so confirm this safety net in CI and add an explicit regression test to prevent a shipped CLI from failing with `MODULE_NOT_FOUND` on `@maka/runtime`'s code-mode import.

## Fix Focus Areas

- scripts/release-cli-package.mjs[236-282]
- scripts/release-cli-package.mjs[301-327]
- scripts/release-cli-package.mjs[448-492]
- scripts/release-cli-package.mjs[559-608]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

3. eval-bundle-path integration untested at cli-core wiring 🐞 Bug ⚙ Maintainability
Description
The new eval-bundle-path.ts unit tests only exercise configureInstalledEvalBundle() in isolation; no
test verifies that cli-core.ts's 'eval' branch actually calls it before dynamically importing
'@maka/eval', so a future regression reordering or removing that call would not be caught by tests.
Code

packages/cli/src/cli-core.ts[R182-183]

+      const { configureInstalledEvalBundle } = await import('./eval-bundle-path.js');
+      configureInstalledEvalBundle();
Relevance

●●● Strong

Accepted precedent favors adding focused regression coverage for missing CLI wiring and behavior
boundaries.

PR-#1587
PR-#2945

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
cli-core.ts's eval case calls configureInstalledEvalBundle() synchronously before awaiting the
dynamic import of '@maka/eval', which is correct ordering, but the only test file
(eval-bundle-path.test.ts) tests the helper function directly with manual environment/packageRoot
arguments and never exercises runMakaCli(['eval', ...]) to confirm the wiring itself.

packages/cli/src/cli-core.ts[179-186]
packages/cli/src/tests/eval-bundle-path.test.ts[8-34]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
There is no test asserting that `runMakaCli(['eval', ...])` invokes `configureInstalledEvalBundle()` before loading `@maka/eval`, leaving the ordering-sensitive integration point in `cli-core.ts` unverified by tests.

## Issue Context
`configureInstalledEvalBundle()` must run before `@maka/eval` is imported since environment variables it sets are read by Eval's runtime functions later, not at module load, but the call ordering itself is only correct by inspection, not by test coverage.

## Fix Focus Areas
- packages/cli/src/cli-core.ts[179-186]
- packages/cli/src/__tests__/eval-bundle-path.test.ts[1-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Full synchronous file read for path-leak check 🐞 Bug ➹ Performance
Description
validateStaging()'s final loop calls readFileSync on every regular file in the staged tree
(including binary native prebuilds) to search for embedded repository paths, with no size limit or
streaming, which can be slow and memory-heavy on a large dependency tree with many files/binaries.
Code

scripts/release-cli-package.mjs[R552-555]

+    const content = readFileSync(path);
+    if (content.includes(Buffer.from(repoRoot))) {
+      throw new Error(`Release file contains the repository path: ${relativePath}`);
+    }
Relevance

●● Moderate

No close precedent; performance concern is plausible but lacks repository-specific evidence of
harmful staging cost.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
walkFiles() enumerates the entire staged tree and validateStaging() reads every file synchronously
into a Buffer via readFileSync before searching for the repo path, including required native .node
prebuilds referenced earlier in the function.

scripts/release-cli-package.mjs[535-556]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
validateStaging()'s repo-path leak check reads every staged file fully into memory synchronously, including large binary native prebuilds, which is unnecessary and can slow down and add memory pressure to the release build as the dependency tree grows.

## Issue Context
The check searches for `Buffer.from(repoRoot)` bytes in file contents to ensure no absolute repository path leaked into shipped artifacts.

## Fix Focus Areas
- scripts/release-cli-package.mjs[535-556]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. npm audit blocks release on any severity 🐞 Bug ☼ Reliability
Description
checkProductionAudit() throws on any nonzero npm audit exit status or any nonzero vulnerability
count with no severity threshold, so a newly disclosed low-severity CVE in a deep transitive
dependency can block every future release attempt with no code change required to fix it.
Code

scripts/release-cli-package.mjs[R213-219]

+  const report = JSON.parse(audit.stdout || '{}');
+  const vulnerabilities = report.metadata?.vulnerabilities;
+  if (audit.error || audit.status !== 0 || vulnerabilities?.total !== 0) {
+    throw new Error(
+      `CLI production dependency audit failed: ${JSON.stringify(vulnerabilities ?? report.error ?? audit.error)}`,
+    );
+  }
Relevance

●● Moderate

No close accepted or rejected precedent; severity-threshold policy is a subjective release-policy
choice.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The audit command runs npm audit --omit=dev --workspace maka-agent --json and the failure
condition is audit.error || audit.status !== 0 || vulnerabilities?.total !== 0, with no severity
or allowlist filtering, so any reported vulnerability of any severity halts the release script.

scripts/release-cli-package.mjs[207-220]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`checkProductionAudit()` fails the release build whenever `npm audit` reports any vulnerability of any severity, with no way to acknowledge/allowlist a specific low-risk advisory pending an upstream fix.

## Issue Context
`npm audit` exits non-zero whenever any vulnerability (including low severity, dev-irrelevant, or non-exploitable-in-this-context) is found. This can make release building fail unpredictably in the future purely due to newly published CVE data with no source change.

## Fix Focus Areas
- scripts/release-cli-package.mjs[207-220]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context
✅ Web pages:
  +7 more
Review mode: 🧠 Deep: This is a high-density release and packaging change spanning substantial new build, dependency-closure, artifact-filtering, native-runtime, security, and install-time behavior with many independent failure modes.

Grey Divider

Tip of the day
💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread scripts/release-cli-package.mjs
Assemble the installed production closure into one public package while preserving private workspace topology, Eval runtime assets, native prebuilds, and reviewed dependency patches. Validate the final artifact and prove an offline global install without registry resolution or install-time builds.

Generated-by: OpenAI Codex
Build publishable CLI artifacts from an isolated archive after an exact npm ci so ignored local dependency changes cannot enter the release. Apply one audited development-file policy to third-party packages during staging and final validation while preserving runtime JavaScript and native assets.

Generated-by: OpenAI Codex
@M4n5ter
M4n5ter force-pushed the feat/cli-npm-tarball branch from c34d22c to ded2081 Compare August 18, 2026 02:42
@M4n5ter

M4n5ter commented Aug 18, 2026

Copy link
Copy Markdown
Member Author

I have reviewed the final revision and accept responsibility for its accuracy, provenance, licensing, and the disclosed AI-assisted content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant