/wbPublish — Exhaustive Simulation ()
/wbPublish is the shipper of packages to npm. Its job is the narrow segment between "tagged release" and "consumers can install it": run the build, validate the manifest, push to the registry, verify the published version is reachable. It does not coordinate versions (that's /wbRelease) and does not deploy apps (that's /wbDeploy).
Read this if you want to know what the four flags do, why --all is dangerous-by-default, and how the publish step interacts with the dist-folder mismatch parked in this workspace's memory.
1. Role & target
| Aspect | Behavior |
|---|---|
| Role | The Shipper — pushes packages to npm. |
| Target | A specific package (default: the one whose tag was most recently created) or --all for every package with a current tag awaiting publish. |
| Cell scope | None directly. |
| Side effects allowed | Running npm publish (or pnpm equivalent); reading the registry to verify post-publish; warning on dist-folder mismatches. |
| Side effects forbidden | Modifying source code; bumping versions (already done by /wbRelease); creating tags; deploying apps. |
The "narrow segment" framing is the design center. The full ship flow has three commands — /wbRelease produces the version state, /wbPublish puts the package on npm, /wbDeploy puts apps on the web. Each command's failure mode is independent: a publish failure doesn't mean rollback the version; a deploy failure doesn't mean unpublish. The seams hold.
2. Argument resolution matrix
| Form | Example | What /wbPublish does |
|---|---|---|
| No argument | Command: /wbPublish | Publishes the package whose latest tag was most recently created and not yet on the registry. |
| Specific package | Command: /wbPublish core2/packages/wb-core | Publishes that one package. Most explicit. |
--all | Command: /wbPublish --all | Publishes every package whose current version isn't on the registry. Sequential; halts on first failure. |
| Free-text | Command: /wbPublish "the auth package" | Refused — path required. |
3. Flag matrix
| Flag | Shortcut | Purpose |
|---|---|---|
--all | -A | Publishes every package in the monorepo whose tag-version isn't already on the registry. |
--dry-run | -d | Validates manifest, runs build, reports what would publish. Does not call npm. |
--prerelease | -p | Publishes with the next (or pre-release) dist-tag instead of latest. Required for pre-release versions like 1.4.0-beta.0. |
--restore | -r | Re-publishes a previously-failed publish attempt (same version) using the same artifacts. Useful when a registry hiccup caused the first attempt to fail mid-upload. |
Why --all is dangerous-by-default
Publishing everything in one command means: if the registry is having issues partway through, you might be left with packages 1-3 published and packages 4-6 not — a half-shipped state. The agent treats --all as needing extra caution:
Without --all | With --all |
|---|---|
| Single package; one decision. | Multi-package; cascading decisions. |
| Failure stops one publish. | Failure stops the chain at whatever point. |
| Confirmation prompt: 1 | Confirmation prompts: per-package + summary. |
Rollback: --restore re-runs the failed publish. | Rollback: --restore per failed publish. |
The agent always recommends not using --all unless the user is intentionally publishing a coordinated multi-package release.
How --dry-run validates
| Step | Live | Dry-run |
|---|---|---|
| Read package.json + check version is tagged | Yes | Yes |
| Build (if needed) | Yes | Yes |
| Validate manifest (files field, main field, exports field) | Yes | Yes |
Check dist-folder reality (does the file main points at exist?) | Yes | Yes |
| Pack tarball | Yes | Yes (cached locally) |
| Push to registry | Yes | Skipped; logs what would push |
| Verify post-push | Yes | Skipped |
The manifest validation is where the dist-folder mismatch surfaces. If main points at dist/index.js but the build wrote to dist-dev/index.js, dry-run catches it before any registry call.
4. Pipelines (the agent-native scenarios)
/wbPublish core2/packages/wbc-ui2-cdn --dry-run> /wbPublish core2/packages/wbc-ui2-cdn --dry-run💠 Pipeline The dry-run that catches the dist-folder mismatch
A real situation in this workspace: core2/packages/wbc-ui2-cdn/ has a parked dist-folder mismatch (per project_pkg_dist_mismatch.md). What happens when someone tries to publish it?
💠 Pipeline A clean single-package publish
💠 Pipeline --all with a partial failure
💠 Pipeline The pre-release path
5. Edge cases & refusals
| Trigger | What /wbPublish does |
|---|---|
| No tag for the version | Halt. Says "run /wbRelease first." |
| Already on registry | Halt. Says "this version is published. Bump first." |
| Dirty working tree | Halt. Same as /wbRelease — clean tree required. |
| Manifest mismatch (main file doesn't exist) | Halt. Suggests the parked-decision conversation if memory flags it. |
--dry-run + --all | Permitted and recommended pattern. |
--restore for a publish that succeeded | Honest "already on registry; nothing to restore." |
| Free-text target | Halt. |
--prerelease for a non-prerelease version (no -beta/-rc suffix) | Halt. The flag and the version must agree. |
| Network/registry failure mid-publish | Reports clearly. --restore re-attempts using the same packed tarball. |
| User asks to unpublish | Refuse. Unpublish is a destructive npm op with policy implications; not in /wbPublish's lane. Tells the user to use npm unpublish directly with full understanding. |
The pattern: /wbPublish is the npm registry interface — narrow, manifest-validating, dist-folder-aware. It refuses to publish bad manifests, refuses to bypass the parked-decision conversation, refuses to silently overwrite latest with pre-releases. The dry-run is the recommended first step, especially for --all which is dangerous-by-default. Memory awareness shows up most clearly here: the dist-folder mismatch parked in project_pkg_dist_mismatch.md is a publish-blocker, and /wbPublish won't paper over it.