search

alexanderGugel / ied

:package: Like npm, but faster - an alternative package manager for Node
http://alexandergugel.github.io/ied
MIT License
1.99k stars 53 forks source link

save-exact support? #88

Open rauchg opened 8 years ago

rauchg commented 8 years ago

In .npmrc one can specify save-exact so that --save and --save-dev don't include ^ by default. I think this should be the default behavior in ied. Thoughts?

derhuerst commented 8 years ago

Isn't the "you can safely upgrade because semver demands a major version bump for every breaking change" notion a really nice one? AFAIK it brought a lot of structure into version in the JS open source world. So why would one explicitly give away this really nice "behavior" of semver?

Remember your proposal is regarding the default, so users that are either unexperienced or use ied infrequently will be affected the most. experienced, every-day users, can customize ied to their preference anyway.

alexanderGugel commented 8 years ago

Hmm... I'm actually a big fan of this. Semver is a great idea in theory, but sometimes stuff breaks. Saving the exact version - at least of the direct dependencies - sounds like a good compromise to me...

alexanderGugel commented 8 years ago

But of course I'm kind of opinionated in that regard.... :D https://github.com/bower/bower/pull/1653

eisisig commented 8 years ago

semver is an awesome idea... Only if everybody would honor the major/minor/patch "rules" :) which not every package maintainer follows... (I've broken them few times). So I approve save-exact

derhuerst commented 8 years ago

By introducing save-exact, you actively take part in not honoring semver. It will never be as widely accepted as it could be if popular projects like ied set "non-semver" to default.

Again, IMHO experienced people should have the possibility to configure save-exact, but not as a default.

rauchg commented 8 years ago

@derhuerst it just doesn't work in the real world. My tests and containers break because of dependencies of dependencies changing under the hood. Case in point, babel, yesterday:

https://travis-ci.org/zeithq/micro/jobs/112767084

Here are my pinned deps: https://github.com/zeithq/micro/blob/master/package.json#L7-L16

Things randomly broke anyway for reasons unknown to me because some dependency of some dependency had a ^ prefix.

It's not about experience or lack thereof. Manifests and version control are supposed give us declarative, deterministic and reproducible builds.

derhuerst commented 8 years ago

@rauchg But still, would configuring ied to save without ^ be a problem to someone like you?

kevgo commented 8 years ago

Semver is an illusion. Every bug fix is per definition a breaking change of existing behavior, and some code might depend on the broken behavior. And it is impossible to guarantee that a non-trivial code change or even a refactoring doesn't break any existing code out there.

The reality is therefore that every update of any dependency must be verified via testing (automated or manual) before deploying to production. The version number change merely gives an indication of the magnitude of changes to expect: a patch release is very unlikely to require code changes, while one should read the release notes and upgrade instructions when moving to a new major release, because its very likely you have to change the way you use the library.

Saving exact version numbers of all dependencies is therefore the only way to guarantee any type of sanity when dealing with a fast moving ecosystem like Node.js. I'd like to encourage ied to use it as the default.

eliperelman commented 8 years ago

Not to just say +1, but +1. Semver is great, but only when it is enforced automatically. In npm, that is not the case. Package maintainers sometimes make mistakes and publish changes under patch and minor versions they didn't realize were breaking changes. This isn't semver's fault; people make mistakes.

Elm uses semver as well, but because the language has static types/inference, versioning is left out of the hands of the package author and put into the platform. You cannot publish breaking changes to non-major versions because exposed APIs are verified through the package manager as to whether having been changed or not in a breaking fashion. This is something that unfortunately cannot be done in JS/npm.

So for those reasons, my vote would be to save-exact by default, and "opt-in" to packages you trust to follow semver by manually managing version ranges.