Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure Renovate #4

Open
wants to merge 1 commit into
base: master
from

Conversation

@renovate
Copy link

renovate bot commented Jan 16, 2018

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)

Configuration

🔡 Renovate has detected a custom config for this PR. Feel free to ask for help if you have any doubts and would like it reviewed.

Important: Now that this branch is edited, Renovate can't rebase it from the base branch any more. If you make changes to the base branch that could impact this onboarding PR, please merge them manually.

You have configured Renovate to use branch master as base branch.

What to Expect

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

chore(deps): pin dependency semantic-release to 6.3.6
  • Schedule: "at any time"
  • Branch name: renovate/pin-dependencies
  • Merge into: master
  • Pin semantic-release to 6.3.6
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.0.3
chore(deps): update dependency semantic-release to v15
  • Schedule: "at any time"
  • Branch name: renovate/major-semantic-release-monorepo
  • Merge into: master
  • Upgrade semantic-release to 15.13.30
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 spam 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 Renovate Bot. View repository job log here.

@LinusU

This comment has been minimized.

Copy link
Contributor

LinusU commented Jan 16, 2018

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

@rarkins

This comment has been minimized.

Copy link

rarkins commented Jan 16, 2018

@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

This comment has been minimized.

Copy link
Contributor

LinusU commented Jan 16, 2018

@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

This comment has been minimized.

Copy link

rarkins commented Jan 16, 2018

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

This comment has been minimized.

Copy link

rarkins commented Jan 19, 2018

@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

This comment has been minimized.

Copy link

sashafirsov commented Mar 14, 2018

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

This comment has been minimized.

Copy link

rarkins commented Mar 15, 2018

@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

This comment has been minimized.

Copy link
Contributor

LinusU commented Mar 15, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.