ChatGPT解决这个技术问题 Extra ChatGPT

What is the difference between Bower and npm?

What is the fundamental difference between bower and npm? Just want something plain and simple. I've seen some of my colleagues use bower and npm interchangeably in their projects.

The answer to this question seems outdated. Can someone tell us what to do in 2016 if we use npm 3 which support flat dependency ? What's the difference wince npm3 and bower and what's the best practice right now ?
Bottom-line, @amdev: bower is now deprecated. npm (or Yarn, which is only a slight difference) is where it's at. I'm not aware of any viable alternatives.

P
Pedro A

All package managers have many downsides. You just have to pick which you can live with.

History

npm started out managing node.js modules (that's why packages go into node_modules by default), but it works for the front-end too when combined with Browserify or webpack.

Bower is created solely for the front-end and is optimized with that in mind.

Size of repo

npm is much, much larger than bower, including general purpose JavaScript (like country-data for country information or sorts for sorting functions that is usable on the front end or the back end).

Bower has a much smaller amount of packages.

Handling of styles etc

Bower includes styles etc.

npm is focused on JavaScript. Styles are either downloaded separately or required by something like npm-sass or sass-npm.

Dependency handling

The biggest difference is that npm does nested dependencies (but is flat by default) while Bower requires a flat dependency tree (puts the burden of dependency resolution on the user).

A nested dependency tree means that your dependencies can have their own dependencies which can have their own, and so on. This allows for two modules to require different versions of the same dependency and still work. Note since npm v3, the dependency tree will be flat by default (saving space) and only nest where needed, e.g., if two dependencies need their own version of Underscore.

Some projects use both: they use Bower for front-end packages and npm for developer tools like Yeoman, Grunt, Gulp, JSHint, CoffeeScript, etc.

Resources

Nested Dependencies - Insight into why node_modules works the way it does


Why doesn't a nested dependency tree do that well on the front end?
Could a front-end npm package not be a flat dependency tree as well? I'm facing the "why do we need 2 package managers?" dilemma.
What do you mean by "flat dependency tree"? Flat tree is what - a list? It's not a tree then.
Actually, a path is also a tree. It is just a special case. From WikiPedia: "In mathematics, and more specifically in graph theory, a tree is an undirected graph in which any two vertices are connected by exactly one path."
npm 3 supports a flat dependency tree now.
r
ruffin

This answer is an addition to the answer of Sindre Sorhus. The major difference between npm and Bower is the way they treat recursive dependencies. Note that they can be used together in a single project.

On the npm FAQ: (archive.org link from 6 Sep 2015)

It is much harder to avoid dependency conflicts without nesting dependencies. This is fundamental to the way that npm works, and has proven to be an extremely successful approach.

On Bower homepage:

Bower is optimized for the front-end. Bower uses a flat dependency tree, requiring only one version for each package, reducing page load to a minimum.

In short, npm aims for stability. Bower aims for minimal resource load. If you draw out the dependency structure, you will see this:

npm:

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

As you can see it installs some dependencies recursively. Dependency A has three installed instances!

Bower:

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

Here you see that all unique dependencies are on the same level.

So, why bother using npm?

Maybe dependency B requires a different version of dependency A than dependency C. npm installs both versions of this dependency so it will work anyway, but Bower will give you a conflict because it does not like duplication (because loading the same resource on a webpage is very inefficient and costly, also it can give some serious errors). You will have to manually pick which version you want to install. This can have the effect that one of the dependencies will break, but that is something that you will need to fix anyway.

So, the common usage is Bower for the packages that you want to publish on your webpages (e.g. runtime, where you avoid duplication), and use npm for other stuff, like testing, building, optimizing, checking, etc. (e.g. development time, where duplication is of less concern).

Update for npm 3:

npm 3 still does things differently compared to Bower. It will install the dependencies globally, but only for the first version it encounters. The other versions are installed in the tree (the parent module, then node_modules).

[node_modules] dep A v1.0 dep B v1.0 dep A v1.0 (uses root version) dep C v1.0 dep A v2.0 (this version is different from the root version, so it will be an nested installation)

dep A v1.0

dep B v1.0 dep A v1.0 (uses root version)

dep A v1.0 (uses root version)

dep C v1.0 dep A v2.0 (this version is different from the root version, so it will be an nested installation)

dep A v2.0 (this version is different from the root version, so it will be an nested installation)

For more information, I suggest reading the docs of npm 3


It's almost a cliché now that "software development is all about trade-offs." This is a good example. One must choose either greater stability with npm or minimal resource load with bower.
@Shrek I'm implicitly stating that you actually can use both. They have different purposes, as I state in the final paragraph. It's not a trade-off in my eyes.
Ahh, I see I misunderstood you. Or I didn't read carefully enough. Thanks for the clarification. :-) It's good that both can be used without a trade-off.
@AlexAngas I've added an update for npm3. It still has some major differences in comparison to Bower. npm will probably always support multiple versions of dependencies, while Bower does not.
npm 3 getting closer to bower ;)
C
Community

TL;DR: The biggest difference in everyday use isn't nested dependencies... it's the difference between modules and globals.

I think the previous posters have covered well some of the basic distinctions. (npm's use of nested dependencies is indeed very helpful in managing large, complex applications, though I don't think it's the most important distinction.)

I'm surprised, however, that nobody has explicitly explained one of the most fundamental distinctions between Bower and npm. If you read the answers above, you'll see the word 'modules' used often in the context of npm. But it's mentioned casually, as if it might even just be a syntax difference.

But this distinction of modules vs. globals (or modules vs. 'scripts') is possibly the most important difference between Bower and npm. The npm approach of putting everything in modules requires you to change the way you write Javascript for the browser, almost certainly for the better.

The Bower Approach: Global Resources, Like