Is your feature request related to a problem? Please describe.
Since @redocly/cli 2.34.0 the published package is a minified esbuild bundle: bin/cli.js, lib/index.js, and hashed chunks. It has no exports field, no lib/reunite/commands/* modules, and no .d.ts files. handlePush, handlePushStatus, and the Reunite response types (PushResponse, DeploymentStatus, and so on) are internal to the bundle.
reunite-push-action used to import these directly. Bumping the CLI broke it (Redocly/reunite-push-action#129, #131, #135). As a bridge, Redocly/reunite-push-action#138 now copies the CLI into the action's dist/, spawns redocly push, parses Push ID: from the text output, and re-implements push-status --wait against the Reunite API to keep GitHub commit statuses working. That means the action owns an endpoint contract the CLI is supposed to own, and it will drift.
Describe the solution you'd like
Expose the Reunite commands as a public programmatic entry point again, for example a second esbuild entry published as @redocly/cli/api, with type declarations:
import { handlePush, handlePushStatus } from '@redocly/cli/api';
import type { PushResponse, PushStatusSummary, DeploymentStatus } from '@redocly/cli/api';
Requirements for the action:
handlePush returns the push id.
handlePushStatus keeps the onRetry callback (or equivalent) that reports the intermediate commit.statuses, because the action mirrors them to GitHub while a deployment runs.
- The entry is bundleable by esbuild without reading
package.json at runtime (the version must stay inlined, as it is in the bin bundle today).
Describe alternatives you've considered
--format json for push and push-status. Then the action becomes a thin wrapper around the binary and stops calling the API itself. Also acceptable, and simpler to keep stable, but the action still has to vendor or install the binary.
- Keep the current bridge in the action. Rejected as the long-term state: duplicated push-status logic and an API contract owned outside the CLI.
Additional context
Is your feature request related to a problem? Please describe.
Since
@redocly/cli2.34.0 the published package is a minified esbuild bundle:bin/cli.js,lib/index.js, and hashed chunks. It has noexportsfield, nolib/reunite/commands/*modules, and no.d.tsfiles.handlePush,handlePushStatus, and the Reunite response types (PushResponse,DeploymentStatus, and so on) are internal to the bundle.reunite-push-action used to import these directly. Bumping the CLI broke it (Redocly/reunite-push-action#129, #131, #135). As a bridge, Redocly/reunite-push-action#138 now copies the CLI into the action's
dist/, spawnsredocly push, parsesPush ID:from the text output, and re-implementspush-status --waitagainst the Reunite API to keep GitHub commit statuses working. That means the action owns an endpoint contract the CLI is supposed to own, and it will drift.Describe the solution you'd like
Expose the Reunite commands as a public programmatic entry point again, for example a second esbuild entry published as
@redocly/cli/api, with type declarations:Requirements for the action:
handlePushreturns the push id.handlePushStatuskeeps theonRetrycallback (or equivalent) that reports the intermediatecommit.statuses, because the action mirrors them to GitHub while a deployment runs.package.jsonat runtime (the version must stay inlined, as it is in the bin bundle today).Describe alternatives you've considered
--format jsonforpushandpush-status. Then the action becomes a thin wrapper around the binary and stops calling the API itself. Also acceptable, and simpler to keep stable, but the action still has to vendor or install the binary.Additional context
src/redocly-cli.ts,src/push-status.ts,src/types.ts). These files should be deleted once the entry point ships.