Skip to content

V3 react support#5

Merged
jontiritilli merged 12 commits into
mainfrom
v3-react-support
May 2, 2026
Merged

V3 react support#5
jontiritilli merged 12 commits into
mainfrom
v3-react-support

Conversation

@jontiritilli

Copy link
Copy Markdown
Contributor

No description provided.

jontiritilli and others added 12 commits May 2, 2026 13:45
Splits working-directory (source) from publish-dir (build output) so
React/Vite/CRA projects can run their build inside the source dir and
publish the artifact emitted next to it. Pipeline now chdirs before
build, so publish-dir resolves correctly relative to working-directory
and the prior './build/build' bug is gone.

Bumps runtime to node22 and rewrites README around the React story.
Rewrite README.md as a complete reference for v3, including:

- Table of contents
- 9 example sections covering Vite, CRA, ProCode/flat, pre-build
  checks, per-environment manifest overrides via `da apply-manifest`,
  multi-env deploys keyed off branch, path-filtered triggers,
  outputs/notifications (Slack + PR comment), and pnpm/yarn setup
- Inputs/outputs reference tables clarifying that `publish-dir` is
  resolved relative to `working-directory`
- "How it works" — explicit 6-step pipeline (detect → install →
  install ryuu → auth → build → publish) so users understand what
  the action does for them
- Callout that no separate `npm install` / `yarn install` /
  `pnpm install` step is needed — the action runs it
- CRA + `da apply-manifest` note: pin `@domoinc/da` as a
  devDependency to avoid `sh: 1: da: not found` in CI's clean install
- Manifest fields table including id/proxyId/collections semantics
- Migration-from-v2 diff explaining why publish-dir was added
- 6-row troubleshooting table covering manifest-not-found, auth,
  duplicate-app id, repo leak (the v2 working-directory trap), the
  da-not-found pattern, and AppDB proxyId

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The package declares engines.node >= 22.0.0 (matching action.yml's
runtime: node22), but both workflows were pinned to setup-node@20.
Yarn 1 enforces engines on install, so CI failed with:

  error domo-publish-action@3.0.0: The engine "node" is incompatible
  with this module. Expected version ">=22.0.0". Got "20.20.2"

Aligning CI to the same Node major the action runs on.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
# Conflicts:
#	action.yml
#	package.json
ryuu reads manifest.json BEFORE its own --build-dir chdir, so
'domo publish --build-dir build' would resolve the manifest from the
caller's cwd (typically a public/manifest.json with no id), causing
ryuu to create a brand-new design on every run instead of updating
the one da apply-manifest baked into build/manifest.json.

Now the action chdirs into publish-dir itself and runs plain
'domo publish'. ryuu's findManifest lands on the resolved manifest
in the build output, sees the id, and updates the existing design.
Release on tag push only creates the pinned-version Release; the
floating major tag (v3) is no longer auto-moved. Promotion is now a
manual workflow_dispatch step so consumers on @V3 don't get new
minors/patches until a human gates the rollout.
Users pin to semver tags (vX.Y.Z) and bump deliberately when they
want a new version. No floating @V3 tag means no surprise updates,
no force-pushes, and one fewer workflow to maintain.
Releases will be cut manually (tag + 'gh release create'). Removing
the auto-release workflow reduces moving parts and keeps tag/release
creation deliberate.
@jontiritilli jontiritilli merged commit 17c9fe6 into main May 2, 2026
1 check passed
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