Packages without a stable release (according to semver) isn't usable

[Hexagon]

Packages without a stable release is currently not usable without specifying an explicit version number

Current behavior

• The default page of jsr.io, example: https://jsr.io/@pup/pup shows nothing but "This package has not published a stable release yet.
• meta.json gives 404: Example https://jsr.io/@pup/pup/meta.json
• deno install fails: Example deno install jsr:@pup/pup gives error: Could not find constraint in the list of versions: @pup/pup

This makes pre-releasing binary packages (?) really hard, as we have to instruct the users to install specific versions like @pup/[email protected], instead of just @pup/pup.

Expected behavior if there are no stable version available:

• The latest pre-release is shown on default page of jsr.io, but with a badge "PRE-RELEASE" or similar
• meta,json is generated, with an additional key "prerelease" containing the latest pre-release version (or something similar)
• deno install jsr:@pup/pup installs the latest pre-release version if there are no stable.

Possible Workaround

When using a non-standard way of pre-releasing, such as giving the prerelease a semver-stable-but-possibly-not-stable version number, such as 0.0.1, everything works fine. The problem only occur when using semver pre-release identifiers.

[lucacasonato]

I propose an alternative:

• For non latest stable versions, the usage instructions say: deno add jsr:@pup/[email protected]
• On the index page, we show the latest pre-release if there are no stable versions at all.
• We do not change the behaviour of deno add jsr:@pup/pup.

[Hexagon]

Has there been any discussions about tags or channels, allowing for something like deno install jsr:@pup/pup@prerelease on a per-project basis? deno install --tag prerelease jsr:@pup/pup would also be an option.

That would relieve the pain from having to update version numbers for every version in pre-release docs.

[lionel-rowe]

Agree with @Hexagon about adding a pseudo version name that will install the latest version regardless of stability, but it'd be useful if it worked everywhere, not just on a per-project basis. Other options could be @unstable or @canary:

deno add jsr:@ns/pkg@unstable

If @ns/pkg has the available versions 1.0.0, 2.0.0-rc.1, and 2.0.0-rc.2, this will install 2.0.0-rc.2. That way you don't have to manually specify the version number when upgrading to bleeding-edge versions (or when using a package that doesn't yet have a stable release).

The index page would still show the unversioned install command (if a stable version is available) and the latest versioned install command (if only unstable versions are available).

Also it'd be nice if unstable releases still showed documentation like other packages. I'm not sure if the lack of docs is intended to nudge authors toward providing a stable version, but if so, there are other ways of doing that (e.g. make the "This package has not published a stable release yet" notice more prominent and with a red background). If the experience of using pre-release versions is so much worse, it'll just incentivise authors to use 0.x.x versions instead.