Configure Renovate

[renovate]

Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

---

Detected Package Files

• package.json (npm)
• .travis.yml (travis)

Configuration Summary

Based on the default config's presets, Renovate will:

• Start dependency updates only once this onboarding PR is merged
• Show all Merge Confidence badges for pull requests.
• Enable Renovate Dependency Dashboard creation.
• Use semantic commit type fix for dependencies and chore for all others if semantic commits are in use.
• Ignore node_modules, bower_components, vendor and various test/tests directories.
• Group known monorepo packages together.
• Use curated list of recommended non-monorepo package groupings.
• Apply crowd-sourced package replacement rules.
• Apply crowd-sourced workarounds for known problems with packages.

🔡 Do you want to change how Renovate upgrades your dependencies? Add your custom config to renovate.json in this branch. Renovate will update the Pull Request description the next time it runs.

---

What to Expect

With your current configuration, Renovate will create 5 Pull Requests:

chore(deps): update dependency semantic-release to v24 [security]

• Branch name: renovate/npm-semantic-release-vulnerability
• Merge into: master
• Upgrade semantic-release to ^24.0.0

chore(deps): update dependency commitizen to v2.10.1

• Schedule: ["at any time"]
• Branch name: renovate/commitizen-2.x
• Merge into: master
• Upgrade commitizen to 2.10.1

chore(deps): update dependency commitizen to v4

• Schedule: ["at any time"]
• Branch name: renovate/commitizen-4.x
• Merge into: master
• Upgrade commitizen to 4.3.0

fix(deps): update dependency conventional-commit-types to v3

• Schedule: ["at any time"]
• Branch name: renovate/conventional-commit-types-3.x
• Merge into: master
• Upgrade conventional-commit-types to ^3.0.0

fix(deps): update dependency longest to v2

• Schedule: ["at any time"]
• Branch name: renovate/longest-2.x
• Merge into: master
• Upgrade longest to ^2.0.0

🚸 Branch creation will be limited to maximum 2 per hour, so it doesn't swamp any CI resources or overwhelm the project. See docs for prhourlylimit for details.

---

❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section.
If you need any further assistance then you can also request help here.

---

This PR has been generated by Mend Renovate. View repository job log here.

[LinusU]

Seems cool, I wonder why default settings is to pin devDependencies to fixed version, why would anyone want to do that? (ping @rarkins 😀)

[rarkins]

@LinusU it’s a risk vs convenience trade-off. The less you pin, the higher the chance of difficult-to-pinpoint dependency breaks, even if you’re using lockfiles. It’s also dependent on how important it is to not have your master branch “broken”. For large projects that might mean man days of inconvenience per break while everyone waits.

For example I helped migrate a repository in the angular org to pinning last week and we found it had two in-range dependency updates that broke the build. They weren’t aware of it as the lockfile was holding versions back by a month or so.

Have a read through https://renovateapp.com/docs/deep-dives/dependency-pinning and let me know if you think any points should be expanded.

Even if you still prefer the risks of dependency ranges, it’s no problem though as Renovate is designed to flexible/configurable. Some people pin everything and get PRs around the clock for every dependency update while others use ranges and want a single (combined) PR once a month.

[LinusU]

@rarkins I have now read the docs for it, and I more understand your position. I can't say that I agree with the conclusions though.

I will only address the scenario with a lock file now since both latest npm and yarn creates them by default, and I don't see why anyone wouldn't use them.

---

As soon as anyone needs to update the lock file (e.g. to add a new dependency, update a feature release of an existing dependency, or simply to refresh the lock file in order to get important patch updates), then your build will then break, because foobar@1.2.0 will get installed.

I don't think that this is true actually. Consider the following package and lock files:

➜  djaslk cat package.json 
{
  "name": "djasda",
  "version": "0.0.0",
  "dependencies": {
    "fs-temp": "^1.0.0",
    "get-random-byte": "^1.0.0"
  }
}
➜  djaslk cat package-lock.json 
{
  "name": "djasda",
  "version": "0.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "fs-temp": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/fs-temp/-/fs-temp-1.0.0.tgz",
      "integrity": "sha1-byqMSJQtoGxxT549l4bhXg+SPvM="
    },
    "get-random-byte": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/get-random-byte/-/get-random-byte-1.0.0.tgz",
      "integrity": "sha512-GSIX2YoaAkDGWhmvbzJX4OAFWfL1Jc5p6mL0cv8L8xzj75Z9XjlZ16avkPdzgjctrOUfXgndHB4gAqM/njEK8w=="
    }
  }
}

Now, the latest version of fs-temp is 1.1.2 and the latest version of get-random-byte is 1.0.1. Let's see what happens when we bump get-random-byte:

➜  djaslk npm add get-random-byte@latest 
+ get-random-byte@1.0.1
updated 1 package in 0.585s
➜  djaslk cat package.json 
{
  "name": "djasda",
  "version": "0.0.0",
  "dependencies": {
    "fs-temp": "^1.0.0",
    "get-random-byte": "^1.0.1"
  }
}
➜  djaslk cat package-lock.json 
{
  "name": "djasda",
  "version": "0.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "fs-temp": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/fs-temp/-/fs-temp-1.0.0.tgz",
      "integrity": "sha1-byqMSJQtoGxxT549l4bhXg+SPvM="
    },
    "get-random-byte": {
      "version": "1.0.1",
      "resolved": "https://registry.npmjs.org/get-random-byte/-/get-random-byte-1.0.1.tgz",
      "integrity": "sha512-DHTqu1lYWYt4gXb8XweiE5DYKyt3JCGFEY3G/xx4bghFGqa8ZpaI/Dgb30kGoNBlznpIqNMvqIYabx0Wk+DCqQ=="
    }
  }
}

As you can see, fs-temp is still at version 1.0.0 and was not upgraded.

---

Once again, if foobar had been pinned to 1.1.0 then it would never have been upgraded to the broken 1.2.0 version “by accident” and rolling it back would again be a matter of reverting the offending commit and regenerating the lock file. New features or updates would not have been held back because of this.

This is only true for your immediate dependencies, and thus pinning will only protect you against breakage in a, in many cases, small percentage of your packages. If you for example have installed express and pinned it, you will only protect yourself against a bad express release, it will not help with the 30 dependencies that express has.

Because of this, I personally think that pinning dependencies just creates a false sense of security, and that using a lock file is superior in every way.

---

Node.js-only libraries can consider pinning all dependencies, because application size/duplicate dependencies are not as much a concern in node.js compared to the browser.

Node.js is used in a lot of more places than beefy servers in the cloud. e.g. It's used in embedded development and many of us are developing on the road over cellular connections, less downloads is nice. Also, many packages intended for Node.js only works great in the browser when used with browserify, webpack, etc.

It also comes with the problem that passing objects from different versions of the same library often doesn't work (e.g. instanceof breaks). This is also stated a bit up in your documentation:

For example, you might have pinned foobar to version 1.1.0 and another author pinned his/her foobar to dependency to 1.2.2. Any user of both your packages will end up with npm attempting to install two separate versions of foobar, which might not even work.

(emphasis mine)

---

If you were using default caret semver ranges, then your master branch is now “broken” because its package.json says that any version 1.x above 1.1.0 is acceptable, and npm will choose the latest (1.2.0). You would need to manually check and work out which dependency caused the failure (foobar may not have been the only dependency to have “automatically” upgraded) and then you would need to pin the dependency yourself to stop npm installing 1.2.0.

This is only a problem when not using lock files, instead of recommending pinning versions, I personally think it's much better to recommend lock files. Especially since pinning only protects one layer down.

---

Sorry for this long dump of my thoughts 🙈 I'm really not trying to be negative against your awesome project! I'm just very passionate about dependency management 😄 ❤️

[rarkins]

Sorry for this long dump of my thoughts

No sorry necessary at all!

I'm a little embarrassed though as I based that article on earlier yarn lock file handing that had the tendency to leave diffs all through a lockfile. I noticed last week how much better yarn is today and thought I'd better update that project but thought I'd check if npm's is just as good before doing so.

I think I will publish an updated revision to that post ASAP and address some of your points in that (both which I agree with or do not). FYI it's actually sourced from the renovate repo so you can file a bug report or PR at any time!

I'm really not trying to be negative against your awesome project!

Don't worry about that, after all Renovate is flexible so all its users can be opinionated. It's intended to operate just as well, however you configure it.

BTW in this case I think you will want to add the preset ": preserveSemverRanges" to the extends array in renovate.json. You also might want to add a preset like ":maintainLockFilesWeekly" too. What that does is regenerate the lock file from scratch, so you can see if the latest versions of everything still pass your build.

[rarkins]

@LinusU FYI I have updated the doc, with a reference to this conversation included: https://renovateapp.com/docs/deep-dives/dependency-pinning

I actually intended to write something more planned and reasoned, but ran out of time this week and wanted to push an update to at least take out the inaccurate parts.

I'm thinking instead of updating it with more "opinionated" arguments, my next step might be a more dry document which describes the various approaches (semver with no lockfile, semver with lockfile, pinned with no lockfile, pinned with lockfile) and how that would work in various scenarios (e.g. minor/patch updates, major updates, breakages, etc). i.e. facts not opinions - something a bit concrete to then base a discussion of opinions on

[sashafirsov]

Article Should you Pin your Javascript Dependencies? is missing an important aspect of enterprise level app: code audit. Only approved by security team binaries are permitted to be used in app. The 'pinning' of revision gives ability to keep revisions compliant.

[rarkins]

@sashafirsov that's an interesting example. In that case, is there any concern about "uncontrollable" indirect/transitive dependencies? Even if you have a lock file, you can't really control what version they get updated to the next time you do an upgrade.

[LinusU]

Only approved by security team binaries are permitted to be used in app. The 'pinning' of revision gives ability to keep revisions compliant.

@sashafirsov but it really doesn't? since you are only pinning your top-level dependencies, anything else could be upgraded at any time.

What would really solve your use case seems like a lock file?

[gkatsanos]

I just run into this thread, trying to understand if/why we need dependency version pinning when a lockfile is present after a technical debate in a project. My general conclusion after reading through the documentation is that pinning can't harm, and it could also potentially make version ambiguities which break the build more obvious, so easier to locate and fix. Is that accurate?
PS: thank you for everyone on devoting time for this discussion, much appreciated.