Can't resolve npm dependencies with a 0.0.0 version and pre-release

[nestarz]

Description

When attempting to import the postgraphile package in Deno 1.44, an error is encountered indicating that the 'tamedevil' package cannot be found, even though it exists on npm. The issue appears to be related to the fact that one of its dependencies is a 0.0.0 version.

Steps to Reproduce

1. Use Deno 1.44.
2. Try to import postgraphile@^5.0.0-beta.26 using the following code:

   import "npm:postgraphile@^5.0.0-beta.26";

3. Observe the error:

   error: Could not find npm package 'tamedevil' matching '^0.0.0-beta.7'.
   

Expected Behavior

The postgraphile package should import successfully without errors related to missing dependencies that exist on npm.

Actual Behavior

The import fails with an error indicating that the 'tamedevil' package cannot be found, despite it being available on npm:

error: Could not find npm package 'tamedevil' matching '^0.0.0-beta.7'.

Additional Information

• Deno version: 1.44
• tamedevil package on npm: tamedevil
• The issue seems to stem from a dependency with a 0.0.0 version, which might be causing the resolution problem.

Suggested Fixes

Ensure that the npm package resolution in Deno correctly identifies and retrieves all dependencies, including pre-release versions and versions starting from 0.0.0, from npm.

Thank you for your assistance!

[dsherret]

The author of that package was just begging to uncover bugs with that versioning strategy. It seems like the node semver calculator doesn't even discover the versions of their package.

The reason this doesn't work is because 0.0.0 is greater than 0.0.0-pre-release in a comparison and we use 0.0.0 as the default lower bound in a version range. I'm looking into fixing it.

[nestarz]

Thanks, @dsherret. Does Node and npm use a semantic versioning (semver) calculator that places versions above 0.0.0-pre-release higher than 0.0.0, but only for 0.0.0 versions? Is this behavior documented to explain why it works this way for them? Maybe it's not related to what comes after the - at this point but instead looks at the timestamp when it was created?

[dsherret]

No, it's 0.0.0 is greater than 0.0.0-pre.

> semver.gt('0.0.0', '0.0.0-pre')
true

We have the same behaviour, but we just have a small bug where we assume 0.0.0 is the min version.

I was referring to this bug on the semver calculator website (https://semver.npmjs.com/):