Open evanweible-wf opened 5 months ago
@evanweible-wf If we decide to stick with the current behavior, having a way to explicitly use the latest would be nice.
For example, something like:
dpx dependency_validator@latest
From what I can tell, this is a known issue in the npx world of things: https://stackoverflow.com/a/74855146, but they do support the @latest
specification that greg mentioned
Parity with npx probably makes the most sense, but if we wanted to get fancy with it, some iterative checking could be interesting
Eg: only for the first execution per day, check version of the script being used. Otherwise just execute what's in the cache. Kind of like how homebrew does it, but during execution of a specific command
If you specify a version constraint when running a package executable, dpx will first check to see if you have a version of that package already globally activated that satisfies that version constraint:
This makes the process faster by avoiding unnecessary network requests.
But, if you're omitting the version constraint for brevity, like this:
Then any version of that package, if already activated, will technically satisfy the omitted version constraint. That may be fine, but it may lead to confusing behavior if you were expecting to be able to use an option or some behavior that was only recently released.
Would a better default be to always try to install the latest version of a package if no version constraint is specified?