How about @beta, @canary, or @next?

Can we bypass cache when a dist-tag is given? Use cache only if no @<tag> was given or a valid semver was given.

• pnpx foo -> use cache

• pnpx foo@14.0.0 -> use cache

• pnpx foo@14.0.0-beta.1 -> use cache

• pnpx foo@14 -> bypass cache

• pnpx foo@next -> bypass cache

• pnpx foo@latest -> bypass cache

@devjiwonchoi Since I am not sure what should be the reasonable expectation for dist tags that aren't "latest", I decide to give the user a choice in the form of a flag.

Even if we ignore cache only when the @latest tag is used. I am not sure it improves user experience.

For instance, you run a command with the @latest tag. However, you do a typo in the arguments. You want to get the previously executed command from history, fix the argument and run the command again. But now everything will be installed again even though only a few seconds passed.

We don’t know what most users prefer. We have a discussion with just few user opinions. I am not sure that’s enough to make a decision.

There are a couple of alternative solutions:

• We could just have a short flag for ignoring the cache. It would work especially well if we’d inform users that cache was used. But unfortunately we were asked in the past to not print anything except of the output of the executed command.
• We could suggest users to clean the dlx cache when they want to be sure that the packages will be fresh.
• We could have a shorter cache lifetime for packages specified via range or dist-tag (1 hour or even 5 minutes?)
• We could resolve packages to exact versions first and then calculate the cache key always by exact versions. This would make the command a little bit slower with cache.

cc @pnpm/collaborators

My two cents here:

We could resolve packages to exact versions first and then calculate the cache key always by exact versions. This would make the command a little bit slower with cache.

This matches with my mental model. When I run with a specific dist-tag, I expect it to match with the registry.

Here's one edge case I can think of:

When a user ran pnpx foo@latest, the registry had 1.0.0. An hour later, it turned out that this version had a breaking bug, so it had a hotfix patch 1.1.0. The user was informed to try the "latest" version again, so they ran again with @latest. As it was cached, the package was still on 1.0.0, and they did not know about it until it broke again. The user reported an issue to the foo package, and the maintainers cannot reproduce it on 1.1.0. Since the PNPM docs don't mention the dlx cache, the user couldn't find it until trying pnpx foo@latest --version.

The same goes for @rc, @beta, etc. IMHO, we should at least fetch for the registry when a dist-tag was given and cache by the exact versions.

The options I'd prefer are one of the following:

1. Cache by exact version, trade-off perf on dlx.
2. Add an option to bypass cache.

Both options need an update of the dlx documentation about the caching.

The discussed solution: #8811