fix(start): sync npm deps on lockfile change and bump builder-sdk to 0.5.0

[eliteprox]

Summary

• ./bin/start.sh now re-runs npm install when package-lock.json is newer than the last install, node_modules is incomplete, or @pymthouse/builder-sdk is missing — fixing the case where an existing node_modules tree leaves newly declared registry deps unresolved after git pull.
• Pins @pymthouse/builder-sdk at 0.5.0 (release notes) across apps/web-next and plugins/developer-api/*.
• Updates docs/pymthouse-integration.md to reflect the new pin and install behavior.

Root cause

start.sh only ran npm install when node_modules/ was entirely absent. Developers who already had a partial install (or pulled after @pymthouse/builder-sdk was added) hit Module not found: Can't resolve '@pymthouse/builder-sdk' on Next.js build even when running ./bin/start.sh --all.

Test plan

• npm install resolves @pymthouse/builder-sdk@0.5.0 at repo root
• apps/web-next pymthouse unit tests pass (pymthouse-client.test.ts, pymthouse-adapter.test.ts)
• Fresh clone / stale node_modules: run ./bin/start.sh --all and confirm dependency sync runs when lockfile changes
• Verify billing/OIDC routes against PymtHouse after SDK bump

Summary by CodeRabbit

• Bug Fixes

  • Improved startup checks so dependency installation/sync runs reliably when the install state is stale or incomplete.
  • Refined setup messaging to clearly distinguish first-time setup from dependency sync.

• Chores

  • Updated the builder SDK dependency to version 0.5.0 across the app and related plugins.
  • Adjusted git hook installation to be more robust and run only when needed.

• Documentation

  • Updated the integration documentation to reflect the 0.5.0 dependency version.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
naap-platform	Ready	Preview	Jul 9, 2026 12:50am

[coderabbitai]

📝 Walkthrough

Walkthrough

Updates @pymthouse/builder-sdk to 0.5.0 across app and plugin package manifests, updates the integration documentation pin, and changes bin/start.sh preflight logic to detect dependency sync needs more precisely and separate git hook installation from initial dependency setup.

Changes

Builder SDK Version Bump

Layer / File(s)	Summary
Dependency version bumps and documentation apps/web-next/package.json, plugins/developer-api/backend/package.json, plugins/developer-api/frontend/package.json, docs/pymthouse-integration.md	@pymthouse/builder-sdk was updated to 0.5.0 in the package manifests and the documented integration pin.
Preflight install/sync refactor bin/start.sh	preflight_check now tracks install state, checks for missing markers, stale lockfiles, and a missing workspace package directory before running npm install/sync, installs git hooks only when absent, and prints distinct completion messages for fresh clone versus dependency sync.

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

Possibly related PRs

• livepeer/naap#406: Also updates @pymthouse/builder-sdk pins in the same package manifests and related integration code paths.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
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.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main changes: syncing npm deps when the lockfile changes and bumping builder-sdk to 0.5.0.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/start-sh-sync-deps-bump-builder-sdk-0.5.0

---

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]

Actionable comments posted: 1

🧹 Nitpick comments (1)

bin/start.sh (1)

158-158: 🩺 Stability & Availability | 🔵 Trivial | 💤 Low value

A && B || C is not a true if-then-else (shellcheck SC2015).

If log_success were to fail (e.g., write error), log_warn would also execute, producing a misleading "Could not install git hooks" message after a successful install. Since log_success is just echo, this is very low risk, but a proper if/then/else would be more robust.

🛡️ Proposed fix: use if/else

-      bash "$SCRIPT_DIR/install-git-hooks.sh" 2>/dev/null && \
-        log_success "Git hooks installed" || log_warn "Could not install git hooks"
+      if bash "$SCRIPT_DIR/install-git-hooks.sh" 2>/dev/null; then
+        log_success "Git hooks installed"
+      else
+        log_warn "Could not install git hooks"
+      fi

🤖 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 `@bin/start.sh` at line 158, The git hooks install flow in start.sh uses an A
&& B || C pattern that is not a reliable if/then/else and can incorrectly
trigger the warning path after a successful install if log_success fails.
Refactor the install-git-hooks.sh invocation block to use an explicit
if/then/else structure, keeping the success path in the then branch and log_warn
only in the else branch, so the behavior is tied to the actual install result
rather than the logging command.

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.

Inline comments:
In `@bin/start.sh`:
- Around line 155-161: The git hooks install block in start.sh is out of sync
with its comment: the current condition around the install-git-hooks.sh call
only checks for missing .git/hooks/pre-push, so it can run on any start, not
just a fresh node_modules creation. Either update the comment near the
hook-install logic to describe the actual behavior, or, if fresh-clone-only
behavior is intended, guard the block with the existing
was_fresh_clone/needs_npm_install state before calling install-git-hooks.sh.

---

Nitpick comments:
In `@bin/start.sh`:
- Line 158: The git hooks install flow in start.sh uses an A && B || C pattern
that is not a reliable if/then/else and can incorrectly trigger the warning path
after a successful install if log_success fails. Refactor the
install-git-hooks.sh invocation block to use an explicit if/then/else structure,
keeping the success path in the then branch and log_warn only in the else
branch, so the behavior is tied to the actual install result rather than the
logging command.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e99f5574-adb3-4eb5-b5b3-0b36a3f3ee19

📥 Commits

Reviewing files that changed from the base of the PR and between 0362427 and 8ae0d64.

⛔ Files ignored due to path filters (1)

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

📒 Files selected for processing (5)

• apps/web-next/package.json
• bin/start.sh
• docs/pymthouse-integration.md
• plugins/developer-api/backend/package.json
• plugins/developer-api/frontend/package.json