Skip to content

[RRFC] remove npm-shrinkwrap.json from the list of unignorable files #511

Open

Description

@ljharb

Motivation ("The Why")

I have npm-shrinkwrap.json in both .gitignore and .npmignore on basically all of my repos. However, I unknowingly broke ls-engines when I published it, not realizing that the npm-shrinkwrap.json i'd been playing with would be published despite being explicitly ignored.

Possible solutions

  • allow npm-shrinkwrap.json to be npmignored
  • fail a publish when an unignorable file is explicitly ignored, via "files" or ".npmignore" or ".gitignore"

The upsides

  • it would be much harder to accidentally break consumers by publishing a shrinkwrap (something that's a long-standing bad practice anyways)

The downsides

  • someone who wants to publish a shrinkwrap would only be able to do so if they weren't already explicitly ignoring it.

Can anyone provide any scenario where making one of the above changes would pose problems for someone?

Activity

  1. added
    semver:majorbackwards-incompatible breaking changes
    Agendawill be discussed at the Open RFC call
    on Jan 17, 2022
  2. dominykas commented on Jan 19, 2022

    @dominykas

    Shouldn't a package-lock be used in the case of a shrinkwrap you don't want published?

  3. ljharb commented on Jan 19, 2022

    @ljharb
    ContributorAuthor

    @dominykas yes, when such a lockfile is intentionally present. In my case, my package actually interacts with other projects' shrinkwrap files, so I'd generated one for testing - but because it was in npmignore, I assumed it would be ignored by npm.

  4. removed
    Agendawill be discussed at the Open RFC call
    on Feb 9, 2022
  5. ruyadorno commented on Feb 9, 2022

    @ruyadorno
    Contributor

    following up from our OpenRFC talk today: npm-shrinkwrap.json being part of the list of unignorable files is a long standing contract that is expected by (at least) some subset of the ecosystems that npm caters to. I'm on the side that completely removing it from that list is too much of a breaking change for too little of an upside (from my pov the subset of package authors that would publish a package containing a npm-shrinkwrap.json unintentionally is much smaller than the subset of package authors intentionally using it).

    On the other hand I'm open to the alternative of making it ignorable via adding to .npmignore (and/or possibly .gitignore) - if the file is listed there it looks to me that the user intent is very clear.

  6. ljharb commented on Feb 9, 2022

    @ljharb
    ContributorAuthor

    I remain convinced that the subset of the infinitesimal number of packages intentionally published with a shrinkwrap file, using files, and not explicitly including it in files, is in the single digits, but I understand it would still technically be a breaking change.

  7. ljharb commented on Mar 18, 2022

    @ljharb
    ContributorAuthor
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

    semver:majorbackwards-incompatible breaking changes

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions