Skip to content

Support range grammar #7

Closed
Closed
@rarkins

Description

@rarkins
Collaborator

So far it's been assumed/tested that existing package.json dependencies use pinned versions, such as 1.6.0 and not such as ~1.6. So for now, this is an undocumented prerequisite of the tool. Ideally we could handle initialising a repo with non-pinned versions and pinning them.

Activity

rarkins

rarkins commented on Dec 18, 2016

@rarkins
CollaboratorAuthor

Given that we prefer not to keep the tool stateless, we can't easily tell if this is the "first" time we've run, i.e. to do a special once-only cleanup. We could use a hack like looking for any past pull requests created by our account, but I prefer to avoid that.

Some possible options:

  • Consider any repo with unpinned dependencies to be "uninitialised" and therefore initialise it if we haven't already
    • Problem: we can't stop developers adding new unpinned dependencies at any time in future
  • Treat any unpinned dependency similar to how we treat an out-of-date pinned dependency
    • Find the highest pinned major and minor updates, and raise a PR for each we find

I think the second option is better, but perhaps there's a problem if someone runs the tool the first time on a repo with completely unpinned dependencies - you could end up with dozens or even hundreds of pull requests.

Perhaps then we provide a special option for the tool where people can manually initialise a repository. e.g. run it with a --initialize parameter and in that case it adopts different behaviour:

  • It creates only one branch/PR, instead of one PR per-dependency
  • It only upgrades dependencies according to their semver, e.g. if it's a tilde range then it only looks for patch upgrades and not minor or major

In theory this shouldn't make any different to the project, because it would simply be pinning the same dependency versions that npm would be resolving anyway.

rarkins

rarkins commented on Dec 18, 2016

@rarkins
CollaboratorAuthor

I wonder if a tool to pin all dependencies already exists, but I can't find it. It's not the same as npm shrinkwrap.

added a commit that references this issue on Jan 10, 2017
32a2f22
locked as resolved and limited conversation to collaborators on Dec 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @rarkins

        Issue actions

          Support range grammar · Issue #7 · renovatebot/renovate