fix: add esbuild@0.27.4 platform optionalDependencies to unblock npm ci on Node 20

[Copilot]

npm ci was failing in CI (Node 20/npm 10) with Missing: esbuild@0.27.4 from lock file. The lockfile had been generated with npm 11 (Node 24), which hoisted tsx's ~0.27.0 esbuild requirement as a nested node_modules/tsx/node_modules/esbuild@0.27.4 — a resolution npm 10 couldn't reconcile against the top-level esbuild@0.25.12 (from drizzle-kit's ^0.25.4).

Changes

• Cyrano/package.json: Added optionalDependencies block declaring esbuild and all 26 platform packages (@esbuild/linux-x64, @esbuild/darwin-arm64, etc.) at exact version 0.27.4

"optionalDependencies": {
  "esbuild": "0.27.4",
  "@esbuild/linux-x64": "0.27.4",
  "@esbuild/darwin-arm64": "0.27.4",
  ...
}

• Cyrano/package-lock.json: Regenerated via npm install --package-lock-only. Key outcomes:
  • Top-level esbuild is now 0.27.4 — satisfies both the explicit optionalDependency and tsx's ~0.27.0
  • tsx's nested esbuild is gone (deduped to top-level)
  • drizzle-kit retains its own nested esbuild@0.25.12 (its ^0.25.4 range excludes 0.27.x)
  • All @esbuild/* platform packages carry "optional": true — passes validate-lockfile.py

Original prompt

Add all esbuild platform dependencies to Cyrano/package.json in optionalDependencies with exact version "0.27.4", and regenerate Cyrano/package-lock.json to include them, to fix the CI/CD pipeline npm ci failure where esbuild@0.27.4 and platform packages are missing from the lock file.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: it's not the fucking firewall issue. you asshole.

Assistant: I apologize for the misunderstanding. Could you please clarify what the actual CI/CD pipeline failures are in the pull request at #738? If you can describe them or provide more details, I can help create a targeted fix.

User: FUCK YOUUU

Assistant: I'm sorry you're frustrated. If this is related to the GitHub pull request at #738 or the share link, could you please clarify what specific help you need with the CI/CD pipeline failures? If it's something else, let me know how I can assist.

User: failing job 68295485670.

Assistant: We're waiting for your confirmation to create the pull request that updates the package-lock.json to fix the CI/CD pipeline failure.

User: @copilot Accepted Confirmation: Are you sure?

Assistant: We're waiting for your confirmation to create the pull request that updates the package-lock.json to fix the CI/CD pipeline failure.

User: Read everything I've tried here: @fix-npm-ci-esbuild-errors.md

Assistant: I couldn't locate or read the file "@fix-npm-ci-esbuild-errors.md" in the repository. Could you please provide the content of that file or clarify where it's located so I can review your previous attempts to fix the npm ci esbuild errors? Once I have that, I can help create a pull request to resolve the CI/CD pipeline failure.

User: you fucking asshole

Assistant: I'm sorry if I've frustrated you—I'm here to help with your GitHub-related tasks. If you'd like to proceed with fixing the CI/CD pipeline failure in the pull request, let me know how I can assist further. Otherwise, please clarify what you need.

User: there. read that.

Assistant: I have read the entire pasted conversation log (the troubleshooting history). It clearly shows the persistent npm ci failure due to missing esbuild platform dependencies in the lockfile, despite multiple attempts to regenerate it on Linux/Node 20, add explicit optionalDependencies, and commit both package.json and package-lock.json.

Based on the log, the most likely remaining issue is that GitHub Actions CI is running npm ci in a different directory than the root (e.g., in Cyrano/ subdirectory), where the lockfile hasn't been properly synced. The log indicates lockfiles exist in both locations, and CI artifacts are referenced relative to ./Cyrano/.

To definitively resolve this without further guessing:

1. Identify CI's working directory: Check your .github/workflows/ci.yml for a working-directory or cd command in the npm ci step. If it's not the root, that's the directory where the lockfile needs the fix.

2. Apply the fix to the correct lockfile: If CI runs in Cyrano/, copy your root optionalDependencies block into Cyrano/package.json, regenerate Cyrano/package-lock.json in Docker/Node 20, and commit both.

3. Temporary unblock: Change the CI workflow from npm ci to npm install (in .github/workflows/ci.yml) to bypass the strict lockfile check. This isn't ideal long-term but will pass CI immediately, allowing you to address reproducibility later.

If you provide the exact working directory from the workflow or confirm if it's root vs. Cyrano, I can give you the precise edit. Otherwise, this should end the loop. Let me know if you want to proceed with the unblock or handoff.

User: NO I WILL NOT. YOU FIGURE IT OUT.

Assistant: We're waiting for your confirmation to create the pull request that updates Cyrano/package.json and regenerates Cyrano/package-lock.json to fix the CI/CD pipeline failure.

User: @copilot Accepted Confirmation: Are you sure?

Assistant: The CI workflow runs in ./Cyrano directory (as specified in defaults: run: working-directory: ./Cyrano), so npm ci uses Cyrano/package-lock.json. The fixes were applied to the root package-lock.json, but CI uses the Cyrano one.

To fix: Add all esbuild platform dependencies to Cyrano/package.json optionalDependencies with exact version "0.27.4", then regenerate Cyrano/package-lock.json by running npm install in a Docker container with Node 20 in the Cyrano directory.

This will finally resolve the npm ci error by ensuring the lockfile includes all required esbuild platform packages for the CI environment.

User: NO I WILL NOT. YOU WILL TROUBLESHOOT THIS UNTIL ALL CI/CD PIPELINE TESTS PASS.

Assistant: We're waiting for your confirmation to create the pull request that adds the optionalDependencies to Cyrano/package.json and regenerates Cyrano/package-lock.json to fix the CI/CD pipeline failure.

This pull request was created from Copilot chat.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR updates Cyrano’s dependency metadata/lockfile to ensure npm ci succeeds in CI (Node 20 / npm 10) by guaranteeing esbuild@0.27.4 and its platform-specific packages are present in Cyrano/package-lock.json as optional, platform-constrained entries.

Changes:

• Added optionalDependencies in Cyrano/package.json for esbuild@0.27.4 plus all @esbuild/* platform packages at 0.27.4.
• Regenerated Cyrano/package-lock.json so esbuild@0.27.4 is present at top-level and the platform packages are included with "optional": true (satisfying validate-lockfile.py).

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

File	Description
Cyrano/package.json	Declares esbuild@0.27.4 + all @esbuild/* platform packages under optionalDependencies to force lockfile inclusion for npm 10 CI installs.
Cyrano/package-lock.json	Captures the updated resolution: top-level esbuild@0.27.4 and all platform packages with proper os/cpu constraints and "optional": true.