Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Shrinkwrap feature #1592
This is WIP PR, do not merge.
As mentioned in #505:
For anyone who doesn't know how
Some subset of it. For example it cannot contain absolute paths, because they'd change between workstations. I think we don't really need nested structure too (or do we?).
We only need
I think we can skip those with
Please also try to test some bower features and judge if
Does it look OK for you?
As for behavior:
I hope it's more or less clear, feel free to discuss this. If implementing, please test it :)
Please speak-up if someone wants to help except @rstacruz I can assign some tasks.
@sheerun what do you mean by "if installation would change bower.lock, it fails with error message" on 2nd point ?
anyway, I have suggestions about for the behavior of
that gives, when no package is specified:
and if packages are specified:
I might be wrong, but it seems that we are trying to make
it could be:
that way, older commands behavior don't need to change (except for creating/updating
@mathroc It means that if someone changes e.g. tag on GitHub, installation fails.
As for modyfying
I'm not sure what you mean.
I don't think we need to add new command.
@mathroc Does it make sense to you?
glad to see works on this, I think this is really needed !
As a ruby developer (backend) I really like bundler and I think using it as reference is a good choice except for "bundle update" as you mentioned which is error prone but when you use git/svn/whatever properly this should never be an issue, you can just revert the lock file.
If possible having an equivalent of
@sheerun ok i think i got you point
I'm not used to bundler so I'm mostly comparing with composer. and with composer you have 3 commands:
the advantage to have the exact-install in composer is that it's very fast, it only download the .lock version of the package (with the commit id not the tag) so if the tag changed on github he does not care and still install the same version as before
checking (and failing) if the tag changed on github might break a deploy that was previously working. it also means that integration test might start failing just because a tag have been changed.
of course it should fail if the commit id does not exists at all and bower cannot download the package
That's the point. We want to prevent deploying different code. It's better to fail for deploy than application.
well, you can also download the tar.gz for a commit id. why have different behaviors for tags & branches ?
I don't get in which use case it makes more sense to fail the
I think I get what you mean.
Wow. I didn't even know it's possible :)
Branches are moving targets while tags are supposed to not be changing. Bower already treats tags and branches differently by caching tags and never caching branches. Tags are equivalent of gem versions in bundler. Also, there are plans to export tags to npm, where commit SHAs won't be available.
I think the ultimate reason is: If you use semver versions, we don't want to assume the underlying platform is VCS. Plus vendors other than GitHub not necessarily provide per-commit tarbars.
One way to detect it is to read metadata bower adds to
Every time tag changes on server, the
Ultimately there's a better way to detect it, though. Earlier I mentioned:
So for semver resolution we'd get instead:
It's just my idea though. If you think there's better way to handle it (introduce new
For bundler I am pretty sure whether you use a branch or tag does not matter it will ultimately resolve to a commit sha1, be careful with how you handle the tags, while a commit id cannot be changed without altering the content the same can't be said with tags, I am sure tags be moved to another commit.
I cannot test that now but consider this:
Always relying on the resolved commit sha1 in lockfile seems safer to me, since the main requirement for me is to ensure nothing will be changed between development and production.
referenced this pull request
Nov 13, 2014
This is crucial, from my perspective it does not make sense without version locking. When more than one person works on project and each of team members has own development environment, there are test and production instances, it's not acceptable to install packages without version consistency. It's best way to keep programmer's stereotype alive: "Works for me!" ;-)
Thanks in advance for implementing this feature, I'm looking forward for it!
Or just write to support an ask to reopen it?
Bower is now deprecated and we recommend to use Yarn or Npm that support file locking.
Here's the guide how to migrate: https://bower.io/blog/2017/how-to-migrate-away-from-bower/