Remove Bower support, make it it's own package

[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]

👎 As I mentioned already.. if anything we should speed it up if running slower than older version, but adding support for more packages for this kind of tool is totally a good idea :) It's like gzip that support more than one file type for zipping files :)

[ghost]

The problem with adding support for more packages is you are increasing the dependencies (and those deps have deps, increasing installation time and size, for a subset of users). There is already a built in way in bower and an npm package to update bower.

If anything this project should remain NPM only (as it's right in the name) and a fork should be created called update-packages or something of that nature. This package was intended to check npm packages for updates and should not deviate from this course because 4 people wanted to add bower bloat to this package.

I know @lipis personally wanted this feature because he uses bower, but he is biased on this issue. I myself would benefit if this package supported JSPM but I don't think it's a good idea to have it in this package, separate npm packages would be ideal. You can have another package (maybe update-packages) that can have optional deps for npm-check-updates, jspm-check-updates, webpack-check-updates and allow a single cmd to update them.

As @metaraine puts it "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."

V3 wastes time and space installing bower & it's dependencies for people who don't use bower. You would still need to run the cmd 2 times, 1 for npm, 1 for bower. In fact it would be easier to run ncu -u, bcu -u, jcu -u and wcu -u than --package bower, --package jspm, `--package webpack'.

[etiktin]

For the time being I think it should stay, mainly because it's already in. We can use the coming weeks to learn what a check update engine needs to support and once we feel comfortable with that, we can separate the engine from the specific package manger implementation. That way, it would be easy to support the next shiny package manger.

I'm not worried about the extra space and time in a global module (it's not like it adds an extra 100MB). What does worry me, is that we need to support different PMs in the same place (code base, issues area etc.), which increases the noise and hurts stability. For example you get a specific issue with Bower, you fix that and you suddenly broke something in npm.

[raineorshine]

Thanks, Robert, for providing your thoughts and insight. I can see arguments for both sides currently, and I'm interested in hearing out other opinions to come to a decision.

I agree that packages that should do one thing, and do it well. One reason for including bower was that the update logic is identical. The core of npm-check-updates is reading semver versions from a JSON file, requesting the latest versions from a package manager, and reporting newer versions. This core logic can work for many package managers. The only difference is in querying the package manager, which currently is decoupled from the core logic. It is a good question whether that should be further decoupled by using separate packages.

You stated that there is already a package that does this for bower. I don't believe this is true, as I searched and only found two packages[1][2], one of which is an exact clone of npm-check-updates, and both of which have already added deprecation notices in favor of using npm-check-updates. Regardless, the discussion about modularity still stands.

1. If we split npm-check-updates into check-updates-core, ncu, bcu, etc, will it create confusion for where to post issues?

An issue could be specific to npm-check-updates, but actually the bug is in check-updates-core. Does this repo continue as-is, or be changed to core? I am concerned about fragmenting support, which is currently consolidated and easy to manager.

2. Can we install specific packages on-demand?

So, the first time you run npm-check-updates it installs the npm dependency, the first time you run ncu -m bower it installs the bower dependency, etc. This would solve the dependency issue that Robert originally brought up.

(Side Note: I am concerned that v3 is running slower than v2, and I am not sure why that occurs. The requests are the same, it was just refactored to use Promises. Maybe there are some blocking tasks in the pipeline that can be parallelized. I will open a separate issue for this.)

[etiktin]

1. I think users will open issues on the front end they are using (e.g. bower users on bcu and npm users on ncu). Once we find an issue that is related to core, we can add a label to it stating that. The fix will be done in core and the task will be updated in the appropriate front end. This is how Electron is dealing with it. Electron doesn't have 2+ interfaces but it is built on top of several other projects (brightray, libchromiumcontent etc.). Most users are not really aware of the different layers, so they just open the task on Electron. The maintainers know where to deal with it, so once they do a PR to a core project, they update the original task. It seems to work pretty good.
   There's also the possibility to have contribution guidelines that will give examples of what types of issues should be posted where.
2. It's possible, but I'm not sure about the experience. For example what if I only want bcu?
   The extra time of downloading the bower support when you're expecting it to just work is not ideal.

[jeandat]

+1 for separation of concern. Bower is another topic. It should be in a separate project.

[vanerleo]

+1 It should be in a separate project.

[alitaheri]

I use ncu on a daily basis and when there are many dependencies ncu takes a long time to complete. I think separating them seems like a better idea. Besides, I don't really think there needs to be a core package, just reuse code, they are completely different concerns after all. I mean not until some time ago I didn't even know it could handle bower too :D

[lipis]

@subjectix Separating them will not speed up your task.. since that kind of expected when you have many dependencies.. I mean it will have to check for each dependency if there is an update before showing the results. The only downside (if someone could consider that a downside) when adding more support is the actual installation time and the size of the package it self. If done correctly nothing else could go wrong.. so lets close this issue and fix the speed, if that's related to the latest updates.

[alitaheri]

@lipis Can't say I don't agree. You are right, that shouldn't affect the speed.

[sidonaldson]

It doesn't bother me that it includes bower but I see the point of those that do not use it. People will install this globally and use it as a tool so why can't it include bower and potentially other variants?
However, npm is huge and used in all different kind of stacks, therefore for the long term good of this project I vote to take it out. (and vote for extensions to plugin additional dependency checking)

[mourner]

I agree that bower support should live in a separate package, or better just removed (sorry). As a maintainer of many popular JS libraries, I would like to see Bower to go away from our lives for good. NPM all the way.

[lipis]

@mourner What else you don't like in this world? Maybe we could also start removing other things in general.. Is Grunt ok? Maybe C++..?

[sidonaldson]

@mourner I used to like bower a lot more but now I can only see one benefit and that's being able to install clientside libraries in a specific folder i.e. /public/js/jquery.js using .bowerrc - even more reason to maintain it separately tho

[mourner]

@lipis not to bash anyone using Bower — it's a great tool that has served a great purpose, but at this moment it simply harms the JS ecosystem and is clearly superseded by NPM while being a pain to support for library authors. In addition, Bower is pretty much not developed anymore.

For a sample discussion of why JS maintainers don't want to support it anymore, see for example reduxjs/redux#944 or bower/bower#1520.

@sidonaldson in practice, you would bundle your scripts for the app anyway no matter what package manager you use (or use CDN links), so it's not a big deal.

[raineorshine]

Thanks for the input everyone. I'm going to encourage people to avoid discussing the broader question of bower vs npm here. This issue has to due with whether bower support should be part of npm-check-updates are separate. bower support is already implemented, so pure for/against arguments are moot. We're just discussing the best architecture for npm-check-updates.

[raineorshine]

For what it's worth (and since I'm currently the main contributor to this library), I'm leaning towards either removing it or having it install-on-demand if I can pull that off.

[lipis]

@metaraine Still not sure why you should do that.. but in the end of the day.. that is your project..

[raineorshine]

I am hearing that others have a desire to separate it out. I consider it
the community's project, even if I'm leading development.
On Mon, Nov 16, 2015 at 3:55 PM Lipis [email protected] wrote:

@metaraine https://github.com/metaraine Still not sure why you should
do that.. but in the end of the day.. that is your project..

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

[ghost]

Error: Cannot find module 'abbrev'
    at Function.Module._resolveFilename (module.js:337:15)
    at Function.Module._load (module.js:287:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (C:\Users\rbaker\AppData\Roaming\npm\node_modules\npm-check-updates\node_modules\bower\lib\index.js:1:76)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (C:\Users\rbaker\AppData\Roaming\npm\node_modules\npm-check-updates\lib\package-managers\bower.js:1:75)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)

Another reason why to separate it out.

This project needs to run ncu on itself, bower is outdated :)

But Bower is now a dead project... Long live WebPack and JSPM!

[avindra]

Please remove Bower. Dead project, and makes the dependency tree for this package insane.

[raineorshine]

v2.5.1

• bower has been removed from the dependency tree.
• bower will be installed on-demand the first time you run -m bower.

🎉 REJOICE 🎉

[avindra]

Rejoices 🎉🎊🎉🎊🎉🎊🎉🎊
On Thu, Nov 19, 2015 at 1:03 PM Raine [email protected] wrote:

v2.5.1

• bower has been removed from the dependency tree.
• bower will be installed on-demand the first time you run -m bower.

[image: 🎉] REJOICE [image: 🎉]

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