Skip to content

Validate that the version is a specific version and doesn't look like a semver version range #415

Closed

Description

@rdimitrov

We may also want to validate that the version is a specific version and doesn't look like a semver version range (prefixed with =, ^, ~, etc)

Originally posted by @connor4312 in #413 (comment)

Activity

  1. domdomegg commented on Sep 10, 2025

    @domdomegg
    Member

    I think I'd be supportive of this if we check nobody has done this in the existing registry data (if they have, we should explore and understand why people have done this / if it's valid etc.).

    Easy to remove the restriction later if it does block valid workflows.

  2. jonathanhefner commented on Sep 11, 2025

    @jonathanhefner
    Member

    I am curious why we would not simply treat these as non-semantic version numbers? The BNF for valid semantic versions is already limited to specific version numbers; range qualifiers such as ^ are defined by package managers (and can vary between package managers). And our documentation already defines how non-semantic versions are handled:

    The registry attempts to parse versions as semantic versions for proper ordering. Non-semantic versions are allowed but will be ordered by publication timestamp.

    If using ranges is a common mistake, we could perhaps add a warning / confirmation in the CLI. Is it a common mistake though?

  3. domdomegg commented on Sep 11, 2025

    @domdomegg
    Member

    I think it makes it likely that clients implementing things like npm packages accidentally install a version range, rather than a specific version. Which makes it harder for subregistries to provide guarantees about specific packages. I think it's very unlikely people really intend to submit a semver version range a lot of the time as an intentional version string - and we could lift this restriction if there's very good reason people are doing this.

  4. jonathanhefner commented on Sep 11, 2025

    @jonathanhefner
    Member

    I think it makes it likely that clients implementing things like npm packages accidentally install a version range, rather than a specific version. Which makes it harder for subregistries to provide guarantees about specific packages.

    My understanding was that this restriction was primarily for the server version (used by the registry itself), similar to the recent restriction on using latest.

    With regards to restricting actual package version numbers, I think we should delegate that responsibility to the package managers themselves. For example, npm already enforces restrictions.

  5. ossamalafhel commented on Sep 14, 2025

    @ossamalafhel
    Contributor

    Hi team,

    I noticed this issue is still open, but it appears to have been implemented in PR #435. The current implementation validates that both server versions AND package versions are not ranges (applying looksLikeVersionRange() to both).

    I see there was some discussion about whether package versions should also be restricted or if the restriction should only apply to server versions (as @jonathanhefner suggested). The final implementation chose the stricter approach of validating both.

    Since the functionality has been implemented, perhaps this issue can be closed? Or is there still discussion needed about whether package versions should be exempt from this validation?

    Thanks!

  6. rdimitrov commented on Sep 15, 2025

    @rdimitrov
    MemberAuthor

    @ossamalafhel - You're right we can close this one, thank you! 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions