fix(ci): sync remotion lockfile

[nathanialhenniges]

npm ci on the macOS runner failed — package-lock.json was missing bundled optional deps (@emnapi/core, @emnapi/runtime under @tailwindcss/oxide-wasm32-wasi). Regenerated with npm install --package-lock-only; npm ci --dry-run passes.

Full release CI test running from this branch: https://github.com/MrDemonWolf/obs-setup/actions/runs/28907868927

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved HEVC export reliability by enabling a software-encoder fallback when hardware encoding isn’t available, increasing success rates for video conversions in CI and virtualized environments.

• Chores

  • Updated the release bundling workflow to run longer and use a newer Node.js setup for more consistent dependency installation, including adjusted caching and install behavior.

[coderabbitai]

Walkthrough

Updates the release bundle job to run longer, switches remotion setup to Node 24 with npm install, and enables software HEVC fallback in the transcode script.

Changes

Release workflow and HEVC script fixes

Layer / File(s)	Summary
Bundle job timeout and Node/npm setup changes .github/workflows/release.yml	Increases timeout-minutes from 90 to 180 and replaces Node 20 + npm ci with Node 24 + npm install --no-audit --no-fund for remotion dependency installation.
HEVC encoder software fallback remotion/to-hevc.sh	Adds -allow_sw 1 to the ffmpeg command and updates the comments describing software encoder fallback behavior.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• MrDemonWolf/obs-setup#3: Touches the same remotion/to-hevc.sh transcoding script used for ProRes→hvc1 conversion.

Poem

A rabbit hops through CI's maze,
Node 24 now leads the ways,
With ffmpeg's soft fallback near,
No hardware fails to fear,
🐇✨ hop, encode, and ship with cheer!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title matches the CI lockfile fix theme and is clearly related to the changes, though it omits the workflow and script updates.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/remotion-lockfile

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

22-22: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Set persist-credentials: false on the checkout step.

No subsequent step in this workflow needs git authentication — release uploads use an explicit GH_TOKEN secret. The default persist-credentials: true stores the GITHUB_TOKEN in .git/config, unnecessarily widening the credential exposure surface.

🔒️ Proposed fix

       - uses: actions/checkout@v4
+        with:
+          persist-credentials: false

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml at line 22, The checkout step in the release
workflow currently leaves the default git credential persistence enabled, which
is unnecessary for this job. Update the actions/checkout setup in the release
workflow to set persist-credentials to false so the GITHUB_TOKEN is not written
into .git/config, while keeping the rest of the release flow unchanged since
upload steps already use GH_TOKEN explicitly.

Source: Linters/SAST tools

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/release.yml:
- Line 22: The checkout step in the release workflow currently leaves the
default git credential persistence enabled, which is unnecessary for this job.
Update the actions/checkout setup in the release workflow to set
persist-credentials to false so the GITHUB_TOKEN is not written into
.git/config, while keeping the rest of the release flow unchanged since upload
steps already use GH_TOKEN explicitly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6b44ab2f-95b5-45a2-8904-7a9555120d19

📥 Commits

Reviewing files that changed from the base of the PR and between 3ae0485 and d7346d7.

⛔ Files ignored due to path filters (1)

• remotion/package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (2)

• .github/workflows/release.yml
• remotion/to-hevc.sh

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

26-39: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Node 24 + npm install switch looks correct.

The lockfile was regenerated with npm 11 (Node 24), so bumping the setup-node action to Node 24 for CI consistency is the right call. The switch from npm ci to npm install is a deliberate, well-documented workaround for npm's bundled-wasm-deps validation failure.

One minor trade-off to keep in mind: npm install can resolve and write new versions into the lockfile during CI (changes are ephemeral since CI doesn't commit), so builds may be slightly less reproducible than with npm ci. If the upstream npm issue (Missing @emnapi/core from lock file) is resolved in a future npm release, consider reverting to npm ci to restore strict lockfile enforcement.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml around lines 26 - 39, The release workflow now
uses Node 24 and npm install, which can update package-lock.json during CI and
make builds less strictly reproducible. Keep the actions/setup-node@v4 Node 24
setup and the Install remotion deps step as-is for the current npm workaround,
but make sure the workflow does not persist lockfile changes and add a clear
note to revert back to npm ci once the bundled-wasm npm issue is fixed. Refer to
the setup-node and Install remotion deps steps when updating this workflow.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/release.yml:
- Around line 26-39: The release workflow now uses Node 24 and npm install,
which can update package-lock.json during CI and make builds less strictly
reproducible. Keep the actions/setup-node@v4 Node 24 setup and the Install
remotion deps step as-is for the current npm workaround, but make sure the
workflow does not persist lockfile changes and add a clear note to revert back
to npm ci once the bundled-wasm npm issue is fixed. Refer to the setup-node and
Install remotion deps steps when updating this workflow.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 17295583-fb83-4814-a5b2-f860a239a20e

📥 Commits

Reviewing files that changed from the base of the PR and between d7346d7 and 14bd62f.

📒 Files selected for processing (1)

• .github/workflows/release.yml