chore(deps): pin dependency in-publish to v2.0.0 - autoclosed

[renovate]

This Pull Request updates dependency in-publish from ^2.0.0 to v2.0.0

---

This PR has been generated by Renovate Bot.

[LinusU]

Wait, do we want this? 🤔

We have a package-lock.json already, I think that this will just make it harder for the end-user to dedupe...

I know that there was some discussion about this earlier 🤔 will try and find...

[jimthedev]

I'm not sure why it is putting this in when it isn't putting it there for others. I will have to investigate.

[LinusU]

here it is: commitizen/cz-conventional-changelog-default-export#4 (comment)

I think we should the configuration to stop pining to specific version. What do you think @jimthedev?

[LinusU]

Aha, this is probably why.

I really wish that this wasn't the default behavior since all apps really should have a package-lock.json file...

---

Wait, actually... 🤔

The default value of rangeStrategy seems to be replace and not auto 🤔

Although that property talks about a pinVersions which I can't find in the documentation, maybe something is stale 🤔

https://renovatebot.com/docs/configuration-options/#rangestrategy

[LinusU]

@rarkins How would you feel about a strategy that works like this?

1. If a package-lock.json is absent, pin devDependencies
2. Pin dependencies if we detect that it's an app, and there is no package-lock.json present.
3. Widen peerDependencies
4. If an existing range already ends with an "or" operator - e.g. "^1.0.0 || ^2.0.0" - then Renovate will widen it, e.g. making it into "^1.0.0 || ^2.0.0 || ^3.0.0".
5. Otherwise, replace the range. e.g. "^2.0.0" would be replaced by "^3.0.0"

I think that this would be a better approach than the current auto, since package-lock.json fixes all the problems that pinning tries to solve, only it actually works ☺️

Basically with the same motivation as our discussion here: commitizen/cz-conventional-changelog-default-export#4 (comment)

[rarkins]

How would you update your lock file and how often? Ie to keep up with bug fixes

[rarkins]

FYI current “auto” behaviour widens any complex OR range as you suggest. The “config:base” preset by default will widen all peer dependencies. Eg if you had ^3.1.0 then it will become “^3.1.0 || ^4.0.0”. I think this makes more sense than changing from 3.x to 4.x only if 3.x still works.

[rarkins]

Renovate without presets (ie tool defaults) will use strategy “replace” for all ranges including complex. If you set to “auto” then it always pins devDependencies and pins dependencies only if it detects an app.

I’m open to an additional rangeStrategy option “pinNotLocked” or “autoPinNotLocked” that means “ auto detect pin only if no lock file present” but I don’t think that should replace the current behaviour of “auto”

[LinusU]

How would you update your lock file and how often? Ie to keep up with bug fixes

Would potentially be cool to make a PR as soon as any dependency en the entire package-lock.json file is updated 😄

That would actually tie in quite nicely into the next thing...

I think that in a lib you don't really want to update your dependencies, just for the sake of it. If you go after the principle that you should release change on master as soon as possible (which I really think that one should), that would most often mean that as soon as any of your dependencies have a new version, you will also have a new version.

With the number of packages that one package can depend on, I don't think that would scale well at all, and it's completely unnecessary since what you want to do is bump the number in your lockfile.

---

Basically, my dream scenario is:

Every package uses ^ do specify both dependencies and devDependencies.

Every package have a package-lock.json (or yarn.lock) committed.

Whenever any dependency in the package-lock.json-file gets a new patch or minor release, a PR is made that updates the package-lock.json file to bump that dependency. (merging this PR in a library should not trigger a release of a new version of the library, anyone depending on you library will get this new version as a PR to their package-lock.json)

Whenever any dependency in the package.json-file gets a new major release, a PR is made that updates the package.json (and lock-file) to bump that dependency. (merging this PR in a library should trigger a release of a new version of the library, whether that is a patch, minor or major release depends on how the library used the updated dependency, and is probably impossible to automate)

If an issue is discovered in the package, which is because of an outdated dependency, a PR should be made that bumps that version package.json (with an update lock-file as well).

---

This approach is the only one that tests each and every smallest unit of change to your code with CI. Whenever any package used, both directly and indirectly, by your package is changed, you will immediately know and the tests will run with that change.

In my opinion, pinning the dependencies is never the right answer, since it will at best only solve a small subset of the potential problems. Worse, it could actually prevent users of your library from getting important bugfixes in downstream dependencies.

---

The more I think about it, I really like this approach. Another great benefit is that as soon as I as a library author releases a new version of my library, every other package that uses that will run their CI. With this in place, we could reverse the flow and automatically open an issue on the library if, say, more than 3 other packages CI broke because of that release.

Before we couldn't do that since every CI run had potentially tons of packages changed between them. But bumping every dep in package-lock.json would allow us to know exactly what version of what library that broke the build.

[LinusU]

I think that this works around another problem: the excessive bumping of packages whenever a dependency has a new version.

Your package should specify which versions that your package works with in the package.json, bumping a dep and releasing a new version without the new version actually affecting your package will just force unneccessary constraints onto your users...

As a library author, I think we should be generous with our ranges since that will make it easier for dedupe to happen. Our users can get these upgrades by bumping their package-lock.json instead, which is a far better way for that to happen.

---

As usual I'm just rambling on about this 😄

[rarkins]

Actually I had a similar idea but was mostly just waiting for someone to ask for it. I hadn’t thought about the benefits to library authors about not bumping releases though, which is an excellent point.

The idea was to have a new rangeStrategy=update-lockfile and it behaves pretty similarly to current except it leaves ranges in package.json and updates the lock file “deliberately” instead once it detects a new version of a direct dependency. Sounds like what you’re after, so now I have a reason to implement :)

[LinusU]

Awesome!