bower.json support

[lipis]

Bunch of projects are using bower.json files and it would awesome if it could also upgrade these packages as well to their latest if defined with a version..!

[raineorshine]

npm-check-updates uses npm heavily, so maybe the bower version would be a
separate repo. The version compatibility semantics would be the same though.

On Wed, Jan 28, 2015 at 8:38 AM, Lipis [email protected] wrote:

Bunch of projects are using bower.json
https://github.com/gae-init/gae-init/blob/master/bower.json files and
it would awesome if it could also upgrade these packages as well to their
latest if defined with a version..!

—
Reply to this email directly or view it on GitHub
#43.

[lipis]

I still believe that it could be part of this one with a separate argument or something instead of having two different repos.. plus this one is already quite popular..

[raineorshine]

It's better to split things up into independent, modular pieces as much as
possible. Take a look at how Express splits most of its functionality into
separate Connect middleware for example.

On Wed, Jan 28, 2015 at 12:27 PM, Lipis [email protected] wrote:

I still believe that it could be part of this one with a separate argument
or something instead of having two different repos.. plus this one is
already quite popular..

—
Reply to this email directly or view it on GitHub
#43 (comment)
.

[raineorshine]

Thinking about this more, I agree this would be very useful. Maybe house them in the same package, but expose two executables: npm-check-updates and bower-check-updates?

[lipis]

It's not node-check-updates or package-check-updates so I still believe that npm-check-updates --bower -u would work just fine.. plus someone could argue that the npm stands for the fact that you are using node to run the process and by having the --bower as an argument makes it more open later on to extend it to the --requirements for example for the requirements.txt file for Python..

What about:

# default will do whatever it was doing..
npm-check-updates -u
npm-check-updates -u --package
npm-check-updates -u --bower
npm-check-updates -u --requirements
npm-check-updates -u --component

and slowly adding on whatever else out there.. :)

[lipis]

Or maybe just something like that:

npm-check-updates -u
npm-check-updates -u package.json
npm-check-updates -u bower.json
npm-check-updates -u requirements.txt

These files always going to have this exact filename otherwise it doesn't make sense.. so this is more extensible :)

[jacobq]

+1 for being able to update bower components as well.
I often use package.json's devDependencies to define what's needed in order to build an app but use another package manager such as bower for front-end assets used in the final product. For now I just copy and rename the bower.json file to package.json in another directory and run your tool, but this still has some problems because not all packages in bower are in npm. (Otherwise why not just use npm for them?)

See also bower-update

[raineorshine]

Thanks Jacob. It's helpful to hear how this is an issue for you. It would
be nice if you didn't have to do that fun workaround :).

On Thu, Feb 12, 2015 at 2:48 PM, Jacob [email protected] wrote:

+1 for being able to update bower components as well.
I often use package.json's devDependencies to define what's needed in
order to build an app but use another package manager such as bower for
front-end assets used in the final product. For now I just copy and rename
the bower.json file to package.json in another directory and run your
tool, but this still has some problems because not all packages in bower
are in npm. (Otherwise why not just use npm for them?)

—
Reply to this email directly or view it on GitHub
#43 (comment)
.

[jmullo]

I actually searched for bower-check-updates immediately after finding this one...

[MichaelBorde]

would be great!

[hum-n]

+1

[lipis]

So what do you think @metaraine.. will we see that any time soon?!

[raineorshine]

Thanks for the feedback. Since many people are interested in this feature, I will make this the next thing to implement. It requires decoupling the package system specifics from the version comparison and update logic.

I have put significant time into development over the last several months: converting everything to Promises, fixing bugs, refactoring, expanding unit test coverage, and updating the output format. All of this is culminating in the v2 release within the next few days. I will need to take a break after all of this work.

If anyone is interested in taking this on I would be happy to support them. Otherwise it will have to wait till later in the year, when I have some free time again.

[lipis]

We can just thank you for all the effort and time @metaraine!! Whenever you have time.. unfortunately my time is also limited but if anyone can help.. it will be much appreciated as well :)

[Climax777]

In the meantime: https://www.npmjs.com/package/bower-update

[se-panfilov]

Just placed it here https://github.com/se-panfilov/bower-check-updates
Yep, it's just a fork with replaced package.json -> bower.json and ncu -> bcu. But anyway it's work right now.
And I merge changes from ncu's repo from time to time.

P.s. My vote is for ncu -u bower.json

[raineorshine]

@se-panfilov Thanks for maintaining the fork during the interim.

One question: Isn't it still searching npm instead of bower? What if something is in the bower registry but not npm, or is different?

(FYI, you could always pipe bower.json to ncu and then write it back to bower.json like this: cat bower.json | ncu --jsonAll > bower.json. As of 2.2.0 you can do ncu --packageFile bower.json)

[zenopopovici]

Hey guys,

I can reply to that question, i've tried to use bcu, it still uses the NPM repo for bower and that makes it unusable.

E.g. for modernizr, on NPM we have version 3.0.0-alpha.4 but on github the latest release is 2.8.3.
Bower checks the git repos directly, it gets the version from the source.

So it's not feasible to just pipe the bower.json to ncu.

[raineorshine]

Thank you, @zenopopovici, that's what I imagined.

It is not a difficult addition, I've just been busy lately and already put considerable time into the project this summer. If anybody has an hour or two free to add this feature, I'll happily review a pull request and advise as needed.

As for the suggested interface, I would prefer having a single command-line option like --packageManager bower rather than separate options for each provider like --npm or --bower as it doesn't pollute the options namespace as much. @se-panfilov: command-line arguments are already being used as a name filter, i.e. ncu -u /^gulp-/.

My suggestion:

ncu -m/--packageManager bower

[Climax777]

I would like to suggest making it more of a flag so that you could update
both bower.json and package.json in the same call.

On Sat, 15 Aug 2015, 21:22 Raine [email protected] wrote:

Thank you, @zenopopovici https://github.com/zenopopovici, that's what I
imagined.

It is not a difficult addition, I've just been busy lately and already put
considerable time into the project this summer. If anybody has an hour or
two free to add this feature, I'll happily review a pull request and advise
as needed.

As for the suggested interface, I would prefer having a single
command-line option like --packageManager bower rather than separate
options for each provider like --npm or --bower as it doesn't pollute the
options namespace as much. @se-panfilov https://github.com/se-panfilov:
command-line arguments are already being used as a name filter, i.e. ncu
-u /^gulp-/.

My suggestion:

ncu -m/--packageManager bower

—
Reply to this email directly or view it on GitHub
#43 (comment)
.

[raineorshine]

@Climax777 Thanks for the suggestion. That would be nice to do both in one call. Since the current output reflects a single set of dependencies, it would have to output separate sections that clearly indicate which package they are for. This, in addition to the fact that npm and bower would be two completely separate API calls and data flows, makes me think simply running them together in bash would be preferable:

ncu -u && ncu -u -m bower

[Climax777]

That is a very good point. One could display the origin next to the
version, in line perhaps.

On Sun, 16 Aug 2015, 03:12 Raine [email protected] wrote:

@Climax777 https://github.com/Climax777 Thanks for the suggestion. That
would be nice to do both in one call. Since the current output reflects a
single set of dependencies, it would have to output separate sections that
clearly indicate which package they are for. This, in addition to the fact
that npm and bower would be two completely separate API calls and data
flows, makes me think simply running them together in bash would be
preferable:

ncu -u && ncu -u -m bower

—
Reply to this email directly or view it on GitHub
#43 (comment)
.

[raineorshine]

Rejoice! Bower support is here.

ncu -m bower

[lipis]

💯 👊

[zenopopovici]

You Sir are awesome!

[lipis]

Maybe adding this line somewhere in the README to have it as an example?

[ghost]

Just updated to v3 and wondered why NPM was installing bower and a bunch of other crap bower needs.

We don't all use or need Bower. I myself use JSPM. There is already and easy built in way to use the latest bower packages within bower, there is also a similar tool available.

I vote to remove bower from this package. Bower support should be a seperate package. This violates NPM/GNU philosophy of small packages that do one thing.

I would like a jspm-check-updates but I would not want it in the same package.

Remove Bower support and move it to it's own package., this was a mistake and you will get more backlash than praise. People are moving away from bower to stuff like JSPM and WebPack.

Bower has increased the installation size and increased dependencies that won't be needed if bower is not used. I'm sure if I JSPM support was added, those who don't use JSPM would be ticked about having an increased install/update time, increased space, and longer processing.

It's also runs slower than the latest v2. I will be downgrading :(

[lipis]

I completely disagree.. I think that's the right place for such utility that upgrades the packages to their latest. It could even support more filetypes instead of removing this one.. we are talking about milliseconds and if anything the other packages shouldn't affect the speed of the individual ones. I'm closing this issues as it's resolved.