Implement 'shrinkwrap' feature

[necolas]

Bower could do with something like npm's shrinkwrap feature to lock down specific versions for deploys.

https://npmjs.org/doc/shrinkwrap.html

This would probably be simpler than what npm has to do, as we'd just need to create a config file to represent the currently installed versions.

Related #416

[sindresorhus]

I want us to do this right, meaning checksum checking for everything to ensure validity. Npm doesn't currently implement this, but are planning to.

[adambiggs]

👍 This would be a really great feature.

[thomaswelton]

Must say 👍 in comparison to the npm and composer install I run bower is super slow. And is a real pain.
I want my repos to be practically empty, and the diffs and commits to be clean. But after going through a phase of committing my bower_components as suggested here #416 I really hated it. Looking forward to this. 😄

[rogeriopradoj]

👍 for sure it will be an excellent feature!

I'm not completely sure how npm works on this, but the way Composer does totally fits my needs.

[OFF-TOPIC]
I'm really happy that the guys in https://github.com/RobLoach/component-installer have built an way to install frontend components via Composer. This is way we can use the composer.lock while the bower.lock (or something close) is not ready. It's a pity there are too few components https://github.com/components/ available, but at least Twitter Bootstrap is there.

[jasoncrawford]

+1. However, I think there's a simple workaround for now. Since Bower's dependency tree is flat, you can just specify exact versions of projects in your bower.json. E.g., specify Bootstrap "2.3.2" instead of "~2.3.2" or "2.3.x" or whatever you do. Then bower install will always install the same versions.

(Of course, the flat dependency tree leeds to version conflict problems, not sure what the long-term solution to that is.)

[necolas]

It's not quite a solution, because your immediate dependencies will have non-fixed version numbers for their dependencies. So even if you lock the versions down, every time bower install is performed, you might get different versions of dependency-dependencies installed.

[jasoncrawford]

Ah, good point. I guess you would have to take all the dependencies (recursively all the way down the tree) and explicitly include them at the top level.

[leostera]

👍

[rubennorte]

I'm joining a little late this discussion, but I'd like to suggest a way to implement this.

I think this could be done the way Bundle does with Gemfile and Gemfile.lock. We could specifiy dependencies in bower.json, install them with bower install or bower update and then a bower.lock (or a more appropiate name) file would be created in the same directory with all the dependencies referencing the exact commit that has been used.

bower.json example:

{
  "name": "my-component",
  "version": "0.1.0",
  "ignore": [
    "**/.*",
    "node_modules",
    "components",
    "bower_components",
    "test",
    "tests"
  ],
  "dependencies": {
    "jquery": "~1.9.0",
    "bootstrap": "~2.3.0",
    "underscore": "~1.4.0"
  }
}

bower.lock example:

{
  "dependencies": {
    "jquery": "#28d946384799abcd7608c3beda898a0a11ac88d7",
    "bootstrap": "#d9b502dfb876c40b0735008bac18049c7ee7b6d2",
    "underscore": "#484bdb43ec4a9dd6a40e60a2d25317bec7aeb43f"
  }
}

Doing so we could deploy exactly the same version of the components we have installed in our development environment without the need of including them in the VC. This could not be a problem for some people, but many components, like jquery-mobile (16 MB), jquery-ui (4.9 MB) or bootstrap (5.1 MB) are including the whole repo as the component (ignoring the ignore option to exclude documentation, tests, binary files, etc.) and making your repo needlessly big.

I think this could be an easy to implement option and that it should be taken into account. I also expect to take some time to implement this and submit a pull request. Meanwhile I'll be watching this thread waiting for your suggestions.

Thanks.

[mikaelkaron]

Would it be better that a final version instead of the commit in the lock file?

Meaning that ~1.2 may result in the exact version 1.2.3 and that's the version that would go into the lock file.

[satazor]

@mikaelkaron as long as we implement checksums, I think it's better to use the version instead of the commit. It's also faster for github endpoints to download versions, instead of checking out commits.

[roelvanduijnhoven]

This would be great to make sure development and production versions are identical!

The activity in this discussion suggest that such a feature is not being worked on at the moment. What can be done to make sure steps are made in the right direction?

[twisk]

👍

[necolas]

What can be done to make sure steps are made in the right direction?

Kick off an implementation design and some code for the feature :)

[stefanpenner]

one issue i see with npm's shrinkwrap over bundlers lockfile, is that the shrinkwrap is not maintained and used to re-validated in all scenarios. This makes it annoying to maintain, and error-prone. I would strongly suggest modeling this around how Gemfile.lock workflow.

[julien-c]

Or composer.lock

[szimek]

+1 for the Bundler-like approach with bower.lock file.

Is it currently possible to programmatically check (e.g. when running grunt server) if user has the current versions of libraries installed?

[hxgdzyuyi]

👍

[evillemez]

+1 for some type of bower.lock. This feature is really important for maintenance.

[kof]

+1, please implement it, currently we are forced to put all the bower components into version control to ensure nothing will change on deployment.

[DavidMikeSimon]

+1 this is crucial for deployment

[shouze]

👍 it's a death or life question

[jeremyFreeAgent]

👍

[fzaninotto]

👍

[faceleg]

This would be like cherries after a lovely sunset.

[kossnocorp]

If we want to have it in the bower we need to decide how it should behave because here is a problem: bower allows to specify package as direct url and there is no way to lock version of package installed this way.

Possible solutions:

1. Force user to add packages installed via direct url to VCS.
2. Create separated directory with such packages and urge developer to commit them.
3. Show warning when user installing package via direct url and explain why it's dangerous.
4. Create community supported dump where we can keep copy of such packages.

Personally I'm prefer 2) but we can start with 3).

What do you think guys?

I'm really interested in this feature.

/cc @satazor, @maccman, @fat.

[greg0ire]

3. would be better IMO, because 2) urges developer to do something that is considered bad practice. Also there is another solution:

4. when installing create a checksum of the downloaded package, and warn when installing on another machine from the bower.lock if the newly downloaded package does not match the checksum.

Note that 5) is not incompatible with 3)

[kossnocorp]

@greg0ire this is bad because it can happen on production server and updated file can contain errors or changed API.

[albertinad]

+1 for lockfile

[syzer]

+1 for resolution key in bower.json

[lsmith77]

since it seems like this feature is taking a long time in the making, maybe an intermediate step would be a script living entirely outside of bower? just take a bower.json file, make a backup copy, traverse what is installed and update the bower.json file with pinned versions of what is currently installed.

[syzer]

@lsmith77 its possible to add custom resolver #1649 and http://bower.io/docs/pluggable-resolvers/

[lsmith77]

see #1748

[dbellettini]

👍 for lockfile

[marco-faustinelli]

👍 for lock file

[twogee]

is #1748 ready for merge?

[avindra]

Switched to an npm / webpack setup and haven't looked back. Still working on migrating off bower, because bower is lacking good support for code modularity and dependency locking. I will say that I still like the bower logo though!

[jpike88]

+1 for this, come on guys I can't take bower seriously until it has a way of locking down dependency versions, how can you develop with peace of mind without this???

[Chekote]

+1 for lockfile

[MelnikVasya]

+1 for lockfile )

[avdd]

Why have a separate lock file when the dependencies can be pinned in bower.json?
But currently it's a pain updating pinned dependencies because bower update becomes a no-op, and bower install has only one option: --force-latest, otherwise you have to manually check and specify the target version.

[derrabus]

@avdd: Like mentioned a couple of times before, you can only pin direct dependencies in bower.json. Indirect/transitive dependencies will always be pulled at their latest compatible version. So pinning in composer.json doesn't cut it.

[avdd]

@derrabus I'm not sure what you mean. Because bower installations are flat and not nested like node, indirect deps become direct deps. If my app uses Foo which requires Bar, I pin versions of both Foo and Bar in my bower.json, which I believe is the point of the feature under discussion?

[derrabus]

@avdd Of course, you can pin the complete dependency graph in your bower.json. But the whole point of a dependency management tool is that you only define your direct dependencies and that it resolves all indirect dependencies for you. What you're describing is a valid workaround, but it's not the solution to the problem.

[greg0ire]

@derrabus @avdd says there is no dependency graph at all : "bower installations are flat". @avdd : what makes you say that ?

[avdd]

@greg0ire bower packages are all installed into one bower_components directory at one level, i.e. flat.

@derrabus it's not a workaround at all. Indirect dependencies are still very much dependencies that should be pinned for repeatable deployments. The dependency graph as such is only a temporary structure used for installing or updating packages. Why bother keeping it?

(I assume we can only be talking about top-level projects and not redistributable packages, which clearly have no use for a shrinkwrap feature.)

[greg0ire]

it's not a workaround at all. Indirect dependencies are still very much dependencies that should be pinned for repeatable deployments.

That's the point of the lock file. On the other hand, when you want to upgrade your top-level dependencies, you don't want to have to find yourself the right version of the indirect deps. That's bower's job, and that's why they should not be kept. Plus if the dependencies have many dependencies that also have dependencies, things could get cumbersome really quickly.

[davidchin]

+1 for lockfile

[benallfree]

Curious to know if anyone is working on this or what the status is?

[subtubes-io]

+1

[gitawego]

+1 for lockfile

[VaclavDedik]

+1

[morrislaptop]

+1

[sheerun]

Please don't +1 this. We need someone skilled to declare to work at least 1-2 weeks on this feature and then maintain it for some time, so I can be sure it is solid and stable enough to release. We need to:

1. Review my current requirements about this feature. Do they cover all the edge cases? What are the ramifications? How can we can achieve backward-compatibility and (even more importantly) forward compatibility of this feature (see: current state of shirnkwrap feature of npm...)
2. Review all the initial code of LockFile Feature #1748 and make sure everything is properly tested.
3. Implement any changes we agreed on in 1.
4. Test in alpha version with out @bower/contributors and deploy first fixes
5. Release it in beta, wait for a feedback
6. Maintain this feature for some time

If someone feels competent enough and is interested in this "gig" (JFrog is eager to pay for time spent on this feature), please post a motivational letter and your availability on my e-mail: sheerun@sher.pl

(e-mail me as well if you just want to volunteer without any liabilities)

[sheerun]

As Bower is not developed anymore, I'm going to close this issue. There are different solutions available right now, specifically npm has package-lock.json and yarn has yarn.lock. On top of this you can convert your current Bower project to yarn with https://github.com/sheerun/bower-away

It's shame this feature never had production-ready implementation, but oh well, time to move on.