LPM-cli

lpm dlx / lpx

Run a package binary without installing it into the project.

lpm dlx <package> [-- args...]
lpx <package> [-- args...]

Fetches a package's binary, caches it under ~/.lpm/cache/dlx/, and runs it without touching your project's package.json or node_modules. The LPM equivalent of npx, pnpm dlx, and bunx.

lpx is a shorthand alias for the same command. lpm dlx remains the canonical long form.

Examples

lpm dlx cowsay "hello"
lpx cowsay "hello"
lpm dlx create-next-app@latest my-app
lpm dlx prettier --check .
lpm dlx http-server -p 8080
lpm dlx --refresh create-next-app   # bypass the dlx cache

How it works

  1. Resolve the spec against the appropriate registry. lpm dlx calls into the full install pipeline, so routing follows the same rules as lpm install: @lpm.dev/* packages go to lpm.dev, .npmrc-declared scopes go to the registry that scope points at, and everything else goes to registry.npmjs.org.
  2. Materialize the package into a cache directory under ~/.lpm/cache/dlx/. The cache entry is keyed by the requested package spec, not by a post-resolution name@version string.
  3. Read the installed package's bin metadata and choose the default executable. If the package exposes exactly one bin, LPM uses it. If it exposes multiple bins, LPM prefers the one matching the package's short name (eslint for eslint, foo for @scope/foo). If there is still no unambiguous default, lpm dlx errors instead of guessing.

lpm dlx <pkg>@<version> pins the requested version. lpm dlx <pkg> reuses the cached entry while it is fresh and prints Reusing dlx cache entry (fresh); once the TTL expires, the next run reinstalls against the current resolution of that spec and reports that it is refreshing the expired cache entry.

Cache TTL

dlx cache entries live for 24 hours. After that, the next invocation reinstalls (loudly — you see a cache expired for <pkg>, reinstalling... line) so you don't keep running an old binary forever. Within the TTL window, repeat invocations are essentially free — the cache entry already has node_modules/.bin/ populated and the binary spawns directly.

Each successful run refreshes the cache mtime, so the TTL is measured from the last successful use, not only from the original install.

--refresh forces an immediate reinstall regardless of the TTL.

Trust model

lpm dlx runs a third-party binary on your machine with no sandbox. LPM strips common secret-bearing env vars and runtime-hijack env vars before spawn, but you should still treat lpm dlx <pkg> as running arbitrary code from that package.

Argument forwarding

Anything after the package name is forwarded to the binary:

lpm dlx prettier --write src/
# runs: prettier --write src/

Cache management

The dlx cache lives at ~/.lpm/cache/dlx/. Manage it with lpm cache:

lpm cache clean dlx     # drop only the dlx cache
lpm cache path dlx      # print the cache root

Bypass the cache for one invocation with --refresh:

lpm dlx --refresh create-next-app

Flags

FlagEffect
--refreshForce a fresh download, ignoring the dlx cache

Plus the global flags.

See also