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

Open
necolas opened this Issue May 27, 2013 · 188 comments

Comments

Projects
None yet
@necolas
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus May 27, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@adambiggs

adambiggs May 29, 2013

👍 This would be a really great feature.

👍 This would be a really great feature.

@thomaswelton

This comment has been minimized.

Show comment
Hide comment
@thomaswelton

thomaswelton 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. 😄

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

This comment has been minimized.

Show comment
Hide comment
@rogeriopradoj

rogeriopradoj 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.

👍 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

This comment has been minimized.

Show comment
Hide comment
@jasoncrawford

jasoncrawford 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.)

+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

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Jun 6, 2013

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jasoncrawford

jasoncrawford 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.

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

This comment has been minimized.

Show comment
Hide comment

ostera commented Jun 11, 2013

👍

@rubennorte

This comment has been minimized.

Show comment
Hide comment
@rubennorte

rubennorte 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.

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

This comment has been minimized.

Show comment
Hide comment
@mikaelkaron

mikaelkaron 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.

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

This comment has been minimized.

Show comment
Hide comment
@satazor

satazor Aug 6, 2013

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@roelvanduijnhoven

roelvanduijnhoven 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?

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

This comment has been minimized.

Show comment
Hide comment

twisk commented Oct 23, 2013

👍

@necolas

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Oct 23, 2013

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner 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.

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

This comment has been minimized.

Show comment
Hide comment
@julien-c

julien-c Oct 23, 2013

Or composer.lock

Or composer.lock

@szimek

This comment has been minimized.

Show comment
Hide comment
@szimek

szimek 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?

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

This comment has been minimized.

Show comment
Hide comment

👍

@evillemez

This comment has been minimized.

Show comment
Hide comment
@evillemez

evillemez Nov 14, 2013

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

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

@kof

This comment has been minimized.

Show comment
Hide comment
@kof

kof 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.

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

This comment has been minimized.

Show comment
Hide comment
@DavidMikeSimon

DavidMikeSimon Nov 18, 2013

+1 this is crucial for deployment

+1 this is crucial for deployment

@shouze

This comment has been minimized.

Show comment
Hide comment
@shouze

shouze Nov 21, 2013

👍 it's a death or life question

shouze commented Nov 21, 2013

👍 it's a death or life question

@jeremyFreeAgent

This comment has been minimized.

Show comment
Hide comment

👍

@fzaninotto

This comment has been minimized.

Show comment
Hide comment

👍

@faceleg

This comment has been minimized.

Show comment
Hide comment
@faceleg

faceleg Nov 28, 2013

Member

This would be like cherries after a lovely sunset.

Member

faceleg commented Nov 28, 2013

This would be like cherries after a lovely sunset.

@kossnocorp

This comment has been minimized.

Show comment
Hide comment
@kossnocorp

kossnocorp 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.

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

This comment has been minimized.

Show comment
Hide comment
@greg0ire

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

  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

This comment has been minimized.

Show comment
Hide comment
@kossnocorp

kossnocorp Nov 28, 2013

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

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

@greg0ire

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire Nov 28, 2013

@kossnocorp how about doing 3) and 5) then ? Warn in both cases ? Also, in 3) does the warning stop the installation process or not (I assumed it does not) ?

@kossnocorp how about doing 3) and 5) then ? Warn in both cases ? Also, in 3) does the warning stop the installation process or not (I assumed it does not) ?

@kof

This comment has been minimized.

Show comment
Hide comment
@kof

kof Nov 28, 2013

checksum should be used in any case, with or without version ... so version actually doesn't matter ... just in case there is no version and somebody tries to install after checksum has changed without to update .lock file ... then it should be inpossible to install and warning should come in place ...

kof commented Nov 28, 2013

checksum should be used in any case, with or without version ... so version actually doesn't matter ... just in case there is no version and somebody tries to install after checksum has changed without to update .lock file ... then it should be inpossible to install and warning should come in place ...

@kossnocorp

This comment has been minimized.

Show comment
Hide comment
@kossnocorp

kossnocorp Nov 28, 2013

@greg0ire 3) + 5) it good for start but this is worst way to solve this problem but it's easy to implement.

@greg0ire 3) + 5) it good for start but this is worst way to solve this problem but it's easy to implement.

@szimek

This comment has been minimized.

Show comment
Hide comment
@szimek

szimek Nov 28, 2013

I might be missing something important here, but haven't libraries like Bundler already solved these problems?

I can specify something like

gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git', :branch => '1.4' 

and it works using sha as its "version".

szimek commented Nov 28, 2013

I might be missing something important here, but haven't libraries like Bundler already solved these problems?

I can specify something like

gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git', :branch => '1.4' 

and it works using sha as its "version".

@greg0ire

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire Nov 28, 2013

@szimek : I think that direct url means : http://some.server.com/jquery-latest.js, but maybe I'm wrong.

@szimek : I think that direct url means : http://some.server.com/jquery-latest.js, but maybe I'm wrong.

@kossnocorp

This comment has been minimized.

Show comment
Hide comment
@kossnocorp

kossnocorp Nov 28, 2013

@szimek bower allows to install packages via direct link (and it's not necessary link to raw on github). For example: https://jqueryrotate.googlecode.com/files/jQueryRotate.js.

@szimek bower allows to install packages via direct link (and it's not necessary link to raw on github). For example: https://jqueryrotate.googlecode.com/files/jQueryRotate.js.

@szimek

This comment has been minimized.

Show comment
Hide comment
@szimek

szimek Nov 28, 2013

@greg0ire @kossnocorp Thanks. Maybe it's going to be simpler to remove such feature :) Yeah, it makes sense for JS libraries.

szimek commented Nov 28, 2013

@greg0ire @kossnocorp Thanks. Maybe it's going to be simpler to remove such feature :) Yeah, it makes sense for JS libraries.

@kossnocorp

This comment has been minimized.

Show comment
Hide comment
@kossnocorp

kossnocorp Nov 28, 2013

@szimek actually this is good point, let's call it 6). Less is more and removing this feature may be good motivation for library authors. Btw it's possible only with changing major version of bower.

@szimek actually this is good point, let's call it 6). Less is more and removing this feature may be good motivation for library authors. Btw it's possible only with changing major version of bower.

@rogeriopradoj

This comment has been minimized.

Show comment
Hide comment
@rogeriopradoj

rogeriopradoj Nov 28, 2013

Composer PHP allows this kind of just one file url install via repository:

Example of a composer.json with a one file url (works for zip files as well, that will be automatically unzipped):

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "bootswatch/united",
                "version": "2.1.1",
                "dist": {
                    "url": "http://bootswatch.com/united/bootstrap.min.css",
                    "type": "file"
                }
            }
        }
    ],

    "require": {
        "bootswatch/united": "2.1.1"
    }
}

And composer.lock stores some hashing, is it correct @Seldaek?

My vote is for something like this in bower too.

Composer PHP allows this kind of just one file url install via repository:

Example of a composer.json with a one file url (works for zip files as well, that will be automatically unzipped):

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "bootswatch/united",
                "version": "2.1.1",
                "dist": {
                    "url": "http://bootswatch.com/united/bootstrap.min.css",
                    "type": "file"
                }
            }
        }
    ],

    "require": {
        "bootswatch/united": "2.1.1"
    }
}

And composer.lock stores some hashing, is it correct @Seldaek?

My vote is for something like this in bower too.

@greg0ire

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire Nov 28, 2013

@rogeriopradoj : do you know how Composer behaves when the content at the given url changes (and the hash is not matched) ?

@rogeriopradoj : do you know how Composer behaves when the content at the given url changes (and the hash is not matched) ?

@avindra

This comment has been minimized.

Show comment
Hide comment
@avindra

avindra Sep 8, 2015

​I've been thinking about switching full to npm as well. Just nice to have the front end vs. backend package separation. Does npm have any way to specify this in the package.json file?

avindra commented Sep 8, 2015

​I've been thinking about switching full to npm as well. Just nice to have the front end vs. backend package separation. Does npm have any way to specify this in the package.json file?

@lolmaus

This comment has been minimized.

Show comment
Hide comment
@lolmaus

lolmaus Sep 8, 2015

Contributor

Bower has been superseded by npm

Source ?

With Browserify and Babel, I do simply:

import _ from 'npm:lodash';

_.range(2); // => [0, 1]

This works in browsers.

And if a package is not published to npmjs.org, it's possible to install directly from GitHub, optionally asking for a specific tag/release, branch or commit:

npm install --save-dev user-name/repo-name@v1.0.2

Tell my why I would still need Bower.

Contributor

lolmaus commented Sep 8, 2015

Bower has been superseded by npm

Source ?

With Browserify and Babel, I do simply:

import _ from 'npm:lodash';

_.range(2); // => [0, 1]

This works in browsers.

And if a package is not published to npmjs.org, it's possible to install directly from GitHub, optionally asking for a specific tag/release, branch or commit:

npm install --save-dev user-name/repo-name@v1.0.2

Tell my why I would still need Bower.

@greg0ire

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire Sep 8, 2015

How is this a source ? What I'm waiting for is a link to a blog post from the author of Bower, saying Bower has been superseded by npm. Good luck.

greg0ire commented Sep 8, 2015

How is this a source ? What I'm waiting for is a link to a blog post from the author of Bower, saying Bower has been superseded by npm. Good luck.

@munro

This comment has been minimized.

Show comment
Hide comment
@munro

munro Sep 8, 2015

robclancy But NPM is slow

Long off topic rant 😹, but you should post your issue on Stackoverflow, if there truly is an issue with NPM caching it will be a welcomed improvement. If all else fails use Docker, or NixOS.

robclancy Oh and shrinkwrap isn't even good enough

Shrinkwrap is good enough because developers cannot deploy the same version twice. [1]

[1] npm/npm-registry-couchapp#148

avindra Does npm have any way to specify this in the package.json file?

NPM at this point is just distribution for assets, webpack and browserify are the mechanisms for compiling on the front end. There's no standard for "front end" packages, since that's really vague. There are standards for JavaScript dependencies, so that will just work. Also webpack is very customizable so you can do all sort of crazy things like flat dependencies, or just flat for lodash & jQuery, or swap them with a CDN, or whatever you can think of! And then just wrap it in a webpack plugin.

greg0ire How is this a source ?

All the source is here: https://www.npmjs.com/ Give it a try!

munro commented Sep 8, 2015

robclancy But NPM is slow

Long off topic rant 😹, but you should post your issue on Stackoverflow, if there truly is an issue with NPM caching it will be a welcomed improvement. If all else fails use Docker, or NixOS.

robclancy Oh and shrinkwrap isn't even good enough

Shrinkwrap is good enough because developers cannot deploy the same version twice. [1]

[1] npm/npm-registry-couchapp#148

avindra Does npm have any way to specify this in the package.json file?

NPM at this point is just distribution for assets, webpack and browserify are the mechanisms for compiling on the front end. There's no standard for "front end" packages, since that's really vague. There are standards for JavaScript dependencies, so that will just work. Also webpack is very customizable so you can do all sort of crazy things like flat dependencies, or just flat for lodash & jQuery, or swap them with a CDN, or whatever you can think of! And then just wrap it in a webpack plugin.

greg0ire How is this a source ?

All the source is here: https://www.npmjs.com/ Give it a try!

@greg0ire

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire Sep 8, 2015

All the source is here: https://www.npmjs.com/ Give it a try!

What the troll ?

What I'm waiting for is a link to a blog post from the author of Bower, saying Bower has been superseded by npm. Good luck.

greg0ire commented Sep 8, 2015

All the source is here: https://www.npmjs.com/ Give it a try!

What the troll ?

What I'm waiting for is a link to a blog post from the author of Bower, saying Bower has been superseded by npm. Good luck.

@lolmaus

This comment has been minimized.

Show comment
Hide comment
@lolmaus

lolmaus Sep 8, 2015

Contributor

@greg0ire By any chance, do you move around town via a carriage? You know, because the carriage owner hasn't publish a confirmation that mules have been superseded by automobiles.

Contributor

lolmaus commented Sep 8, 2015

@greg0ire By any chance, do you move around town via a carriage? You know, because the carriage owner hasn't publish a confirmation that mules have been superseded by automobiles.

@greg0ire

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire Sep 8, 2015

I don't think mules vs automobiles is the same debate as npm vs bower or emacs vs vim. My point is, don't come here stating your personal opinion as a fact. I don't see many carriage users in town, buty I know many bower users.

greg0ire commented Sep 8, 2015

I don't think mules vs automobiles is the same debate as npm vs bower or emacs vs vim. My point is, don't come here stating your personal opinion as a fact. I don't see many carriage users in town, buty I know many bower users.

@munro

This comment has been minimized.

Show comment
Hide comment
@munro

munro Sep 8, 2015

lolmaus

If only they did, good point that these sort of things happen organically. I added a small code bounty to this issue a year ago—since then I've just found myself using npm more. Even in #Node.js they're actively recommending NPM and deterring Bower use, though an article would be nice to make it less confusing for new comers. Relevancy isn't decided by the project [1], but through hard work one can try to stay relevant [2].

[1] https://github.com/bower/bower/graphs/contributors?from=2014-10-04&to=2015-09-05&type=c
[2] https://github.com/npm/npm/graphs/contributors?from=2014-10-04&to=2015-09-05&type=c

munro commented Sep 8, 2015

lolmaus

If only they did, good point that these sort of things happen organically. I added a small code bounty to this issue a year ago—since then I've just found myself using npm more. Even in #Node.js they're actively recommending NPM and deterring Bower use, though an article would be nice to make it less confusing for new comers. Relevancy isn't decided by the project [1], but through hard work one can try to stay relevant [2].

[1] https://github.com/bower/bower/graphs/contributors?from=2014-10-04&to=2015-09-05&type=c
[2] https://github.com/npm/npm/graphs/contributors?from=2014-10-04&to=2015-09-05&type=c

@belka-ew

This comment has been minimized.

Show comment
Hide comment
@belka-ew

belka-ew Sep 10, 2015

+1 for lockfile

+1 for lockfile

@saschanos

This comment has been minimized.

Show comment
Hide comment
@saschanos

saschanos Sep 12, 2015

+1 for lockfile

+1 for lockfile

@PedroSena

This comment has been minimized.

Show comment
Hide comment
@PedroSena

PedroSena Sep 22, 2015

+1 for lockfile

+1 for lockfile

@albertinad

This comment has been minimized.

Show comment
Hide comment
@albertinad

albertinad Sep 22, 2015

+1 for lockfile

+1 for lockfile

@syzer

This comment has been minimized.

Show comment
Hide comment
@syzer

syzer Sep 29, 2015

+1 for resolution key in bower.json

syzer commented Sep 29, 2015

+1 for resolution key in bower.json

@lsmith77

This comment has been minimized.

Show comment
Hide comment
@lsmith77

lsmith77 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.

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

This comment has been minimized.

Show comment
Hide comment

syzer commented Sep 29, 2015

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

@lsmith77

This comment has been minimized.

Show comment
Hide comment

see #1748

@dbellettini

This comment has been minimized.

Show comment
Hide comment
@dbellettini

dbellettini Oct 6, 2015

👍 for lockfile

👍 for lockfile

@marco-faustinelli

This comment has been minimized.

Show comment
Hide comment
@marco-faustinelli

marco-faustinelli Oct 6, 2015

👍 for lock file

👍 for lock file

@twogee

This comment has been minimized.

Show comment
Hide comment
@twogee

twogee Oct 13, 2015

is #1748 ready for merge?

twogee commented Oct 13, 2015

is #1748 ready for merge?

@avindra

This comment has been minimized.

Show comment
Hide comment
@avindra

avindra 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!

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

This comment has been minimized.

Show comment
Hide comment
@jpike88

jpike88 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???

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

This comment has been minimized.

Show comment
Hide comment
@Chekote

Chekote Oct 16, 2015

+1 for lockfile

Chekote commented Oct 16, 2015

+1 for lockfile

@MelnikVasya

This comment has been minimized.

Show comment
Hide comment
@MelnikVasya

MelnikVasya Oct 23, 2015

+1 for lockfile )

+1 for lockfile )

@avdd

This comment has been minimized.

Show comment
Hide comment
@avdd

avdd 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.

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

This comment has been minimized.

Show comment
Hide comment
@derrabus

derrabus 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.

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

This comment has been minimized.

Show comment
Hide comment
@avdd

avdd 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?

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

This comment has been minimized.

Show comment
Hide comment
@derrabus

derrabus 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.

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

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire Nov 3, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@avdd

avdd 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.)

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

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire 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.

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

This comment has been minimized.

Show comment
Hide comment
@davidchin

davidchin Nov 10, 2015

+1 for lockfile

+1 for lockfile

@benallfree

This comment has been minimized.

Show comment
Hide comment
@benallfree

benallfree Nov 12, 2015

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

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

@edgar-humberto

This comment has been minimized.

Show comment
Hide comment
@gitawego

This comment has been minimized.

Show comment
Hide comment
@gitawego

gitawego Dec 8, 2015

+1 for lockfile

gitawego commented Dec 8, 2015

+1 for lockfile

@VaclavDedik

This comment has been minimized.

Show comment
Hide comment

+1

@morrislaptop

This comment has been minimized.

Show comment
Hide comment

+1

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Dec 9, 2015

Contributor

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)

Contributor

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.