gitignored package-lock.json

[satazor]

I prefer to gitignore the package-lock.json for libraries. I commit the package-lock.json only for apps.
When the package lock is gitignored, when running standard-version this happens:

✔ committing package-lock.json and package.json and CHANGELOG.md
The following paths are ignored by one of your .gitignore files:
package-lock.json
Use -f if you really want to add them.

Command failed: git add package.json package-lock.json CHANGELOG.md
The following paths are ignored by one of your .gitignore files:
package-lock.json
Use -f if you really want to add them.

Using -f will add the package-log to source control which I don't want. Ideally, standard-version could detect that the file is gitignored and skip it.

Thoughts?

[nexdrew]

@satazor Hey, I ran into this same problem today, bit of a pain.

Besides manually running npm i --no-package-lock (to avoid the creation of the lock file at all) or adding package-lock.json to the git repo, here are a couple workarounds/hacks I tested that were successful:

1. Rename package-lock.json on prebump and rename it back on posttag

   Define a standard-version lifecycle script in your package.json that looks like this:

   "standard-version": {
     "scripts": {
       "prebump": "mv package-lock.json package-lock-IGNORE.json",
       "posttag": "mv package-lock-IGNORE.json package-lock.json"
     }
   }

   This maintains the integrity of the lock file but temporarily hides it when running standard-version.

   I put this as the first option because it still allows you to get the benefit of using package-lock.json file locally, though that value is arguably moot when not shared.

2. Remove package-lock.json on postshrinkwrap

   Define an npm postshrinkwrap script that looks like this:

   "scripts": {
     "postshrinkwrap": "rm -f package-lock.json",
     "release": "standard-version"
   }

   This just subverts the normal lock file writing process that occurs with a typical npm i (npm will create the file and then immediately delete it on install). This works whether you're using standard-version or not.

   (Note that I also tried to do this with a postinstall script, but postinstall runs before npm creates the lock file.)

3. Remove package-lock.json on prebump

   Define a standard-version lifecycle script in your package.json that looks like this:

   "standard-version": {
     "scripts": {
       "prebump": "rm -f package-lock.json"
     }
   }

   This just removes the file when you go to cut a new release. The next time you run npm i, the lock file will be recreated.

That being said, it would obviously be nice if standard-version detected that the file is git-ignored, but until we can add that, one of the above options is probably the best we can do. HTH!

[satazor]

@nextdrew thanks for your suggestions, haven’t really thought of them. Nicely done. Regarding windows support, replacing rm with rimraf works?

[nexdrew]

@satazor Yes, good point, rimraf package-lock.json should work cross-platform.

[bcoe]

@nexdrew @satazor slick; perhaps a good topic for putting in docs/advanced.md?

[danielo515]

Hello,
I'm also suffering this problem. Is the package-lock already ignored or should I go for the prebump workaround ?

[jbottigliero]

With #230 (and likely some updates since), standard-version will respect .gitignore. Since the package-lock.json is a bit of a special case (default bumpFile), I've expanded our test to make sure it is ignored as expected when found in a local .gitignore.

Thanks to all who contributed to this initial fix/feature! ✌️