Build React WASM package from same-run artifact

[sfmskywalker]

Fixes #1048

The React wrapper package step used npm version inside the npm workspace. That re-resolved the checked-in lockfile and attempted to download @elsa-workflows/elsa-studio-wasm@3.4.0 from Feedz, even though the same package workflow had already built the current WASM tarball.

The step now sets the wrapper and its WASM dependency to the workflow's $VERSION, installs from the same-run tarball with the workspace lock disabled, then builds and packs the wrapper. The install runs from the workspace root so its postinstall copies assets from the hoisted package that came from that tarball.

Validation:

• Reproduced the Feedz 404 locally with npm version.
• From a clean npm workspace install, installed a synthetic same-run WASM tarball, built the React wrapper, and packed it.
• Inspected the packed package.json; wrapper version and WASM dependency matched exactly.
• Workflow YAML parsed and git diff --check passed.

The Packages workflow only runs on pushes to main or release events, so this PR does not execute that packaging job before merge.

[greptile-apps]

Confidence Score: 4/5

Not safe to merge until the wrapper build preserves a deterministic dependency graph.

Findings

1.  Unlocks Release Dependencies ▶

Fix with agent prompt

### Issue 1
.github/workflows/packages.yml:126
This install disables the workspace lockfile while building the release wrapper, so dependencies other than the local WASM tarball resolve from manifest ranges instead of the checked-in pins. A newly published dependency version can therefore change or break a release built from unchanged source, while the unchanged lockfile no longer describes what was built. This must be fixed before merging.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The wrapper package now installs the WASM tarball created in the same run, but the install ignores the checked-in dependency lock. This allows unrelated dependencies to change between releases built from the same source.

_{Reviews (1) · Last reviewed commit: "fix(ci): build React wrapper from same-r..."}

[greptile-apps]

Unlocks Release Dependencies

This install disables the workspace lockfile while building the release wrapper, so dependencies other than the local WASM tarball resolve from manifest ranges instead of the checked-in pins. A newly published dependency version can therefore change or break a release built from unchanged source, while the unchanged lockfile no longer describes what was built. This must be fixed before merging.

Artifacts

Evidence from the check

• This authored shell script creates an isolated npm workspace, a locally packed WASM-like tarball, and a deliberately stale lockfile before executing the exact line-126 npm options; it is the executable test source.

Command output from the check

• This captured execution ran the supplied reproduction from `/home/user/repo` with exit code 0 and shows lodash changed from lockfile pin 4.17.20 to installed 4.18.1 while the lockfile hash stayed unchanged, confirming nondeterministic release dependencies.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/packages.yml
Line: 126

Comment:
**Unlocks Release Dependencies**

This install disables the workspace lockfile while building the release wrapper, so dependencies other than the local WASM tarball resolve from manifest ranges instead of the checked-in pins. A newly published dependency version can therefore change or break a release built from unchanged source, while the unchanged lockfile no longer describes what was built. This must be fixed before merging.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.