[ChristopherPHolder]

The problem

packages/cli/package.json declares:

"bin": { "user-flow": "src/cli.mjs" }

On current main the build emits that file to dist/packages/cli/packages/cli/src/cli.mjs. There is no dist/packages/cli/src/cli.mjs, so the next publish would ship a package whose user-flow binary points at a missing file — npx @push-based/user-flow would fail for every consumer.

This is a regression, not long-standing. The published 0.21.4 tarball has it correctly at package/src/cli.mjs.

Cause

Nx 24 changed how @nx/js:tsc resolves string assets — the full path is now preserved rather than relativised to the project root. All four string entries were affected, not just the binary:

"assets": [
  "README.md",
  "packages/cli/*.md",
  "packages/cli/src/cli.mjs",
  "packages/cli/*.schema.json",
  "packages/cli/**/static/**"
]

packages/nx-plugin was unaffected because it already uses the object form ({input, glob, output}), which is why only the CLI broke.

Surfaced while adding the plugin e2e suite in #292 — the published tarball contents are visible in the local-registry publish output.

The fix

Converted the string assets to the object form so output paths are explicit.

Verification

Packed dist/packages/cli and diffed the file list against the published 0.21.4 tarball:

=== only in published (missing from new build) ===
=== only in new build ===
=== counts: published=312 built=312 ===

Identical in both directions. Also confirmed node dist/packages/cli/src/cli.mjs --version runs, and that the static/ assets and CHANGELOG.md / README.md land where they did before.

Note: packages/cli/*.schema.json matches nothing in the source tree today — it was a no-op before this change and still is. Left in place rather than widening the scope of the fix.

[github-actions]

❗❗❗ report generated by this PR ❗❗❗

☕ Order Coffee ☕

Date/Time: 2026-10-23 20:39

Step Name	Gather Mode	Performance	Accessibility	Best Practices	Seo
🧭 Navigate to coffee cart	navigation	92	93	100	83
☕ Select coffee	timespan	17/17	-	8/8	-
✔ Coffee selected	snapshot	Ø 1/1	16/18	4/4	3/5
🛒 Checkout order	timespan	19/19	-	8/8	-
🧾 Order checked out	snapshot	Ø 1/1	18/19	4/4	3/5
💌 Submit order	timespan	18/18	-	8/8	-
📧 Order submitted	snapshot	Ø 1/1	20/22	4/4	3/5
🧭 Navigate to github	navigation	98	92	100	83

[ChristopherPHolder]

Closing — the premise was wrong, and I got this one backwards.

I concluded the build emitted cli.mjs to dist/packages/cli/packages/cli/src/cli.mjs by inspecting a dist/ that had accumulated across several local e2e runs. That nested path was a stale artifact, not current output.

A clean build with main's existing config:

$ git checkout origin/main -- packages/cli/project.json
$ rm -rf dist/packages/cli && nx run cli:build --skip-nx-cache
$ find dist/packages/cli -name cli.mjs
dist/packages/cli/src/cli.mjs

$ ls dist/packages/cli/
CHANGELOG.md  README.md  package.json  src

Correct path, no stray packages/ directory. main is fine and there is nothing to fix.

Two independent confirmations I should have weighed before opening this:

• user-flow-md-report-test runs node ./dist/packages/cli/src/cli.mjs after a fresh npm run build-cli, and passes on main-based branches. It could not have passed if the premise held.
• The published 0.21.4 tarball was produced by this same config and has package/src/cli.mjs.

The "312 files, identical in both directions" check in the description was real, but it only proved the rewritten config was equivalent to the published package — not that the existing config was broken. It was equivalence, not a fix.

The two CI failures here were also unrelated to the change. Both trace to /home/runner/.npm/_npx/.../node_modules/@push-based/user-flow — the published CLI fetched by npx, which this PR does not touch. The published CLI declares puppeteer: ^24.24.0, which npx resolves to 24.43.1, requiring Chrome 148.0.7778.97; meanwhile npx puppeteer browsers install chrome installs Chrome for the workspace's lockfile-pinned 24.24.0. That drift breaks any workflow that invokes the published CLI through npx and is independent of this branch — worth a separate look, but not this one.