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

Implement 'shrinkwrap' feature #505

Closed
necolas opened this issue May 27, 2013 · 189 comments
Closed

Implement 'shrinkwrap' feature #505

necolas opened this issue May 27, 2013 · 189 comments
Labels

Comments

@necolas
Copy link
Contributor

@necolas necolas commented May 27, 2013

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
Copy link
Contributor

@sindresorhus sindresorhus commented May 27, 2013

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
Copy link

@adambiggs adambiggs commented May 29, 2013

👍 This would be a really great feature.

@thomaswelton
Copy link

@thomaswelton thomaswelton commented Jun 3, 2013

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
Copy link

@rogeriopradoj rogeriopradoj commented Jun 3, 2013

👍 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
Copy link

@jasoncrawford jasoncrawford commented Jun 6, 2013

+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
Copy link
Contributor Author

@necolas necolas commented Jun 6, 2013

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
Copy link

@jasoncrawford jasoncrawford commented Jun 6, 2013

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.

@ostera
Copy link

@ostera ostera commented Jun 11, 2013

👍

@rubennorte
Copy link

@rubennorte rubennorte commented Jul 18, 2013

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
Copy link

@mikaelkaron mikaelkaron commented Aug 6, 2013

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
Copy link
Member

@satazor satazor commented Aug 6, 2013

@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
Copy link

@roelvanduijnhoven roelvanduijnhoven commented Oct 23, 2013

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
Copy link

@twisk twisk commented Oct 23, 2013

👍

@necolas
Copy link
Contributor Author

@necolas necolas commented Oct 23, 2013

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
Copy link

@stefanpenner stefanpenner commented Oct 23, 2013

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
Copy link

@julien-c julien-c commented Oct 23, 2013

Or composer.lock

@szimek
Copy link

@szimek szimek commented Oct 28, 2013

+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
Copy link

@hxgdzyuyi hxgdzyuyi commented Nov 6, 2013

👍

@evillemez
Copy link

@evillemez evillemez commented Nov 14, 2013

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

@kof
Copy link

@kof kof commented Nov 18, 2013

+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
Copy link

@DavidMikeSimon DavidMikeSimon commented Nov 18, 2013

+1 this is crucial for deployment

@shouze
Copy link

@shouze shouze commented Nov 21, 2013

👍 it's a death or life question

@jeremyFreeAgent
Copy link

@jeremyFreeAgent jeremyFreeAgent commented Nov 21, 2013

👍

1 similar comment
@fzaninotto
Copy link

@fzaninotto fzaninotto commented Nov 27, 2013

👍

@faceleg
Copy link
Member

@faceleg faceleg commented Nov 28, 2013

This would be like cherries after a lovely sunset.

@kossnocorp
Copy link

@kossnocorp kossnocorp commented Nov 28, 2013

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
Copy link

@greg0ire greg0ire commented Nov 28, 2013

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

  2. 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
Copy link

@kossnocorp kossnocorp commented Nov 28, 2013

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

@syzer
Copy link

@syzer syzer commented Sep 29, 2015

+1 for resolution key in bower.json

@lsmith77
Copy link

@lsmith77 lsmith77 commented Sep 29, 2015

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
Copy link

@syzer syzer commented Sep 29, 2015

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

@lsmith77
Copy link

@lsmith77 lsmith77 commented Sep 30, 2015

see #1748

@dbellettini
Copy link

@dbellettini dbellettini commented Oct 6, 2015

👍 for lockfile

@marco-faustinelli
Copy link

@marco-faustinelli marco-faustinelli commented Oct 6, 2015

👍 for lock file

@twogee
Copy link

@twogee twogee commented Oct 13, 2015

is #1748 ready for merge?

@avindra
Copy link

@avindra avindra commented Oct 13, 2015

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
Copy link

@jpike88 jpike88 commented Oct 15, 2015

+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
Copy link

@Chekote Chekote commented Oct 16, 2015

+1 for lockfile

@MelnikVasya
Copy link

@MelnikVasya MelnikVasya commented Oct 23, 2015

+1 for lockfile )

@avdd
Copy link

@avdd avdd commented Nov 3, 2015

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
Copy link

@derrabus derrabus commented Nov 3, 2015

@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
Copy link

@avdd avdd commented Nov 3, 2015

@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
Copy link

@derrabus derrabus commented Nov 3, 2015

@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
Copy link

@greg0ire greg0ire commented Nov 3, 2015

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

@avdd
Copy link

@avdd avdd commented Nov 3, 2015

@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
Copy link

@greg0ire greg0ire commented Nov 4, 2015

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
Copy link

@davidchin davidchin commented Nov 10, 2015

+1 for lockfile

@benallfree
Copy link

@benallfree benallfree commented Nov 12, 2015

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

@le-garden-fox
Copy link

@le-garden-fox le-garden-fox commented Nov 18, 2015

+1

@gitawego
Copy link

@gitawego gitawego commented Dec 8, 2015

+1 for lockfile

@VaclavDedik
Copy link

@VaclavDedik VaclavDedik commented Dec 8, 2015

+1

1 similar comment
@morrislaptop
Copy link

@morrislaptop morrislaptop commented Dec 8, 2015

+1

@sheerun
Copy link
Contributor

@sheerun sheerun commented Dec 9, 2015

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 #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)

@bower bower locked and limited conversation to collaborators Dec 9, 2015
@sheerun
Copy link
Contributor

@sheerun sheerun commented Apr 26, 2020

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.

@sheerun sheerun closed this Apr 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.