Pin npx wrapper to mise node runtime

[timohubois]

Updates Omarchy's generated npx wrappers to run both node and npx from the same mise where node@latest install instead of invoking npx from PATH.

Background

This builds on the previous fix in #5247, which moved wrappers to mise-managed Node to avoid shell-local Node drift (for example with direnv).

That fix addressed Node selection, but wrappers could still pick up a different npx binary. This change pins both node and npx to the same mise-managed runtime and adds a migration to regenerate existing wrappers accordingly.

[Copilot]

Pull request overview

Pins Omarchy’s generated npx wrappers so both node and npx are executed from the same mise-managed node@latest install (avoiding PATH drift where npx could come from a different runtime).

Changes:

• Update omarchy-npx-install to resolve the node@latest install root via mise where and execute node + npx from that same root.
• Add a migration to regenerate existing shipped wrappers using the updated wrapper template.

Reviewed changes

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

File	Description
migrations/1776348723.sh	Regenerates the default set of npx wrappers to pick up the new pinned-runtime wrapper logic.
bin/omarchy-npx-install	Changes generated wrapper to run node and npx from the same mise where node@latest install path.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Pins Omarchy-generated npx wrappers so both node and npx are executed from the same mise-managed node@latest installation (avoiding drift between the selected Node runtime and whatever npx happens to be on PATH).

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Changes:

• Update omarchy-npx-install to resolve the mise node@latest install root and execute node + npx from that install explicitly.
• Add a migration to regenerate existing wrappers using the updated wrapper template.

Reviewed changes

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

File	Description
migrations/1776348723.sh	Adds a migration to rerun wrapper generation via install/packaging/npx.sh.
bin/omarchy-npx-install	Updates generated wrapper contents to invoke node/npx directly from the mise node@latest install root.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dhh]

Could you share a concrete reproduction where mise exec node@latest -- npx picks up a foreign npx? My understanding is that mise exec prepends the runtime's bin directory to PATH for the duration of the child process, so npx should resolve to the same install as node.

[timohubois]

@dhh Thanks for the feedback! I dug into this more and was able to reproduce it in a mixed shell setup (direnv + Nix + mise).
In that environment, running:
mise exec node@latest -- npx ...

can fail to keep npx coupled to the selected node runtime rather than the node@latest selected by mise, leading to errors such as:
Error: Cannot find module 'node:path'

A key part of the issue is that npx is a #!/usr/bin/env node script. Even when invoked via an absolute path, it can still pick up a different node from the ambient PATH, so $node_root/bin/npx alone isn’t sufficient to guarantee consistency.

I tried a few alternatives (mise exec, --fresh-env, shims, direct paths), but they weren’t reliable in this setup.

The fix I’m proposing now is to ensure the wrapper resolves both node and npx from the same runtime:

export PATH="$node_root/bin:$PATH"
exec "$node_root/bin/npx" --yes ...

This keeps the fix wrapper-local and ensures that npx resolves the matching node, even in mixed environments.

From my perspective, this fix makes sense if the wrapper is intended to keep npx launchers independent of the shell and tied to the selected mise Node runtime. I really appreciate your perspective on this. If I’ve misunderstood the intended scope, I’m happy to close the PR.