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 cacheHow it works
- Resolve the spec against the appropriate registry.
lpm dlxcalls into the full install pipeline, so routing follows the same rules aslpm install:@lpm.dev/*packages go to lpm.dev,.npmrc-declared scopes go to the registry that scope points at, and everything else goes toregistry.npmjs.org. - 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-resolutionname@versionstring. - Read the installed package's
binmetadata 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 (eslintforeslint,foofor@scope/foo). If there is still no unambiguous default,lpm dlxerrors 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 rootBypass the cache for one invocation with --refresh:
lpm dlx --refresh create-next-appFlags
| Flag | Effect |
|---|---|
--refresh | Force a fresh download, ignoring the dlx cache |
Plus the global flags.
See also
lpm exec— run a local filelpm install -g— keep a CLI around permanently insteadlpm cache— manage the dlx cache