Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

No ticket. Update npm devDependencies.

  • Loading branch information...
commit 95d1192d5378926e750d0494818323ff17be821e 1 parent 35b2b94
Michał Gołębiowski mzgol authored
Showing with 3 additions and 3 deletions.
  1. +3 −3 package.json
6 package.json
View
@@ -28,14 +28,14 @@
],
"dependencies": {},
"devDependencies": {
- "archiver": "~0.4.9",
+ "archiver": "~0.4.10",
Oleg Gaidarenko Collaborator

@mzgol Why did you update these dependencies? They have ~ so we would not do so

Michał Gołębiowski Collaborator
mzgol added a note

@markelog Why not? I was updating 'grunt-contrib-json' so I've changed other entries as well in the same commit.

Oleg Gaidarenko Collaborator

It's unnecessary noise and somewhat confusing. Only real change here is a minor version bump for grunt-contrib-jshint. Which was noticed by the @sindresorhus and now he did not get credit for it. I'm sure @sindresorhus is cool with it, but if it was someone else, he could get upset. So i would suggest to not mix up this kind of changes whenever they are in same plane or not.

Michał Gołębiowski Collaborator
mzgol added a note

@markelog Ok, I get the noise argument. As for giving credit... Come on, if anyone gets upset because of not being credited for a minor version bump, I'd say they have a problem with themselves.

OTH, sth like #1405 or #1407 definitely deserves credit.

Oleg Gaidarenko Collaborator
I'd say they have a problem with themselves.

Agreed, but we love all people, even the ones that have problems :-). Besides, i was talking in a general sense.

I am curious for why the use ~ if you are updating the versions manually.
~ already updates the minor version by default when there is one available.

Michał Gołębiowski Collaborator
mzgol added a note

@markelog :)

@FagnerMartinsBrack I've already replied to @markelog that that's true. ;) grunt-contrib-jshint had to be updated as the minor version, not the patch version changed.

Michał Gołębiowski Collaborator
mzgol added a note

@markelog I've just checked and packages specified with ~ don't auto-update themselves. What is done is if you're missing a package it will install the latest matching one but if you already have one, npm install won't update it. IMO it means that updating dependencies manually makes sense as new patch versions usually fix bugs.

Scott González Owner

Can we please just switch to specific version numbers? We've already been bitten multiple times in jQuery projects from using version ranges.

Michał Gołębiowski Collaborator
mzgol added a note

@scottgonzalez +1. I'm willing to update dependencies manually from time to time myself.

On the other hand, providing specific version numbers is not a universal remedy. Those packages have their own dependencies and they are often provided in a non-strict way so we'll still be left with non-consistent package versions and there's no way around that. If node_modules was a small directory we could as well commit it to the repo but it's not, it's huge so it won't happen.

Unfortunately, npm doesn't have an analogue of gem's Gemfile.lock that provides the whole tree of mappings package -> version number. I consider it one of npm's major faults.

Dave Methvin Owner

I would vote for exact versions as well. Non-specific versioning has caused a lot of trouble, especially when Grunt moved from 0.3 to 0.4.

Something like bundledDependencies or npm-shrinkwrap seems like overkill, our dependencies haven't caused that much trouble.

Scott González Owner

@mzgol npm does have shrinkwrap, but I agree with @dmethvin that it's overkill for our needs.

While Grunt 0.3 -> 0.4 is a good example of the code breaking on us, we wouldn't have that specific problem with the ranges currently listed, since ~0.3.0 wouldn't match an 0.4 release.

But we've been bitten by bugs introduced in patch versions of our dependencies. We all know software isn't perfect, and bugs introduced through version ranges are often tricky to track down.

Dave Methvin Owner

The Grunt API breaking change came on a 0.4RC so ~ wouldn't have worked there either. We had a repo and SHA in the dependencies for about a month.

Scott González Owner

Oh yeah. I forgot about the whole 0.4RC fiasco. So Grunt actually is a great example :-)

Oleg Gaidarenko Collaborator
IMO it means that updating dependencies manually makes sense as new patch versions usually fix bugs.

No, it does not. If you already has installed npm packages and you want to update them, you should use npm update not npm install. Hence the name.

I'm willing to update dependencies manually from time to time myself.

Then what's the point of tilde removal? If you just gonna do it manually? I say let's remove tilde and use specific versions, update patch version of the package if we noticed some bugs with it, but only if update would help, or if it has new minor or major versions, we could even automate it through build task and irc bot.

Dave Methvin Owner

I don't mind doing these kind of dependency updates manually when they're needed, to fix bugs that affect us. Doing it automatically just leads back to the same headaches we are trying to avoid by using imprecise dependency specs like ~ or >=.

Oleg Gaidarenko Collaborator

@dmethvin I meant notify us through irc if some package is outdated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
"grunt": "~0.4.1",
"grunt-compare-size": "~0.4.0",
- "grunt-contrib-jshint": "~0.6.4",
+ "grunt-contrib-jshint": "~0.7.0",
"grunt-contrib-uglify": "~0.2.4",
"grunt-contrib-watch": "~0.5.3",
"grunt-git-authors": "~1.2.0",
- "grunt-jsonlint": "~1.0.0",
+ "grunt-jsonlint": "~1.0.1",
"gzip-js": "0.3.2",
"testswarm": "~1.1.0",
"requirejs": "~2.1.9",
Oleg Gaidarenko
Collaborator

@mzgol Why did you update these dependencies? They have ~ so we would not do so

Michał Gołębiowski
Collaborator

@markelog Why not? I was updating 'grunt-contrib-json' so I've changed other entries as well in the same commit.

Oleg Gaidarenko
Collaborator

It's unnecessary noise and somewhat confusing. Only real change here is a minor version bump for grunt-contrib-jshint. Which was noticed by the @sindresorhus and now he did not get credit for it. I'm sure @sindresorhus is cool with it, but if it was someone else, he could get upset. So i would suggest to not mix up this kind of changes whenever they are in same plane or not.

Michał Gołębiowski
Collaborator

@markelog Ok, I get the noise argument. As for giving credit... Come on, if anyone gets upset because of not being credited for a minor version bump, I'd say they have a problem with themselves.

OTH, sth like #1405 or #1407 definitely deserves credit.

Oleg Gaidarenko
Collaborator
I'd say they have a problem with themselves.

Agreed, but we love all people, even the ones that have problems :-). Besides, i was talking in a general sense.

Fagner Brack

I am curious for why the use ~ if you are updating the versions manually.
~ already updates the minor version by default when there is one available.

Michał Gołębiowski
Collaborator

@markelog :)

@FagnerMartinsBrack I've already replied to @markelog that that's true. ;) grunt-contrib-jshint had to be updated as the minor version, not the patch version changed.

Michał Gołębiowski
Collaborator

@markelog I've just checked and packages specified with ~ don't auto-update themselves. What is done is if you're missing a package it will install the latest matching one but if you already have one, npm install won't update it. IMO it means that updating dependencies manually makes sense as new patch versions usually fix bugs.

Scott González

Can we please just switch to specific version numbers? We've already been bitten multiple times in jQuery projects from using version ranges.

Michał Gołębiowski
Collaborator

@scottgonzalez +1. I'm willing to update dependencies manually from time to time myself.

On the other hand, providing specific version numbers is not a universal remedy. Those packages have their own dependencies and they are often provided in a non-strict way so we'll still be left with non-consistent package versions and there's no way around that. If node_modules was a small directory we could as well commit it to the repo but it's not, it's huge so it won't happen.

Unfortunately, npm doesn't have an analogue of gem's Gemfile.lock that provides the whole tree of mappings package -> version number. I consider it one of npm's major faults.

Dave Methvin

I would vote for exact versions as well. Non-specific versioning has caused a lot of trouble, especially when Grunt moved from 0.3 to 0.4.

Something like bundledDependencies or npm-shrinkwrap seems like overkill, our dependencies haven't caused that much trouble.

Scott González

@mzgol npm does have shrinkwrap, but I agree with @dmethvin that it's overkill for our needs.

While Grunt 0.3 -> 0.4 is a good example of the code breaking on us, we wouldn't have that specific problem with the ranges currently listed, since ~0.3.0 wouldn't match an 0.4 release.

But we've been bitten by bugs introduced in patch versions of our dependencies. We all know software isn't perfect, and bugs introduced through version ranges are often tricky to track down.

Dave Methvin

The Grunt API breaking change came on a 0.4RC so ~ wouldn't have worked there either. We had a repo and SHA in the dependencies for about a month.

Scott González

Oh yeah. I forgot about the whole 0.4RC fiasco. So Grunt actually is a great example :-)

Oleg Gaidarenko
Collaborator
IMO it means that updating dependencies manually makes sense as new patch versions usually fix bugs.

No, it does not. If you already has installed npm packages and you want to update them, you should use npm update not npm install. Hence the name.

I'm willing to update dependencies manually from time to time myself.

Then what's the point of tilde removal? If you just gonna do it manually? I say let's remove tilde and use specific versions, update patch version of the package if we noticed some bugs with it, but only if update would help, or if it has new minor or major versions, we could even automate it through build task and irc bot.

Dave Methvin

I don't mind doing these kind of dependency updates manually when they're needed, to fix bugs that affect us. Doing it automatically just leads back to the same headaches we are trying to avoid by using imprecise dependency specs like ~ or >=.

Oleg Gaidarenko
Collaborator

@dmethvin I meant notify us through irc if some package is outdated.

Please sign in to comment.
Something went wrong with that request. Please try again.