Skip to content

Detect package manager instead of hardcoding npx in docs and CLI output #129

@Stanzilla

Description

@Stanzilla

Summary

The Intent docs and CLI responses currently hardcode npx in installation/usage instructions. It would be better to detect the package manager used by the current project and render commands accordingly (pnpm dlx, yarn dlx, bunx, npx, etc.).

This applies to both:

  • Web documentation
  • CLI output / suggested follow-up commands

Why this matters

Hardcoding npx is problematic for projects that do not use npm as their package manager:

  1. npx is noticeably slower than the native package-manager runner in many environments.
  2. More importantly, npx bypasses package-manager-specific policy and security controls configured by the repository.

For example, pnpm supports security-related settings such as minimumReleaseAge. If Intent tells users to run an npx command in a pnpm-managed repo, that command may not respect the repo's pnpm policy expectations.

Expected behavior

Intent should detect the package manager from the current workspace where possible, using files such as:

  • packageManager in package.json
  • pnpm-lock.yaml
  • yarn.lock
  • bun.lock / bun.lockb
  • package-lock.json

Then documentation/CLI suggestions should use the matching runner. For example:

pnpm dlx @tanstack/intent@latest list

instead of:

npx @tanstack/intent@latest list

Fallback behavior

If no package manager can be detected, falling back to npx seems reasonable. But when the project clearly uses pnpm/yarn/bun, the generated instructions should avoid npm-specific commands.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions