Consider deprecating Bower.

[trusktr]

And encourage NPM + Webpack/Browserify/etc workflows. I don't intend to introduce hard feelings or anything like that, but those other workflows are superior in many ways, and maybe we should encourage people to move to them for the greater good of the Web/JavaScript community as a whole.

[calidion]

@trusktr

Feel free to use npm as your package management, but don't be bothered with the existence of bower.
npm is good at managing versions and packages.
But I don't think npm is a replacement of bower.

After updating to version 3, npm introduces many problems.
Bower is a much cleaner and easier way for front end project management.
And it can also take advantages from npm.
By using both bower and npm, we can clearly tell from which are tooling packages to which are core packages of front end projects.
It would be very useful and you won't be lost in the package hell which npm3 now has introduced, where even the smallest project will get hundreds of packages installed.

npm 3 is no better in managing node modules than 2.x, let alone front end modules.
npm 3 is somewhat a mass to package management comparing to its previous versions and makes no progress.
npm has also violated the basic Unix principal: do one thing and do it well.

npm should be improved to be the node package management tool.
and
bower should be improved as the front end package management tool.
They may have something in common, but totally two different directions.

[cmmata]

@trusktr That's the same kind of comment as if I say to deprecate grunt because gulp has many improvements. I think it's good to have choices. Maybe in one project you see that gulp is better, but in another one you prefer grunt because of one plugin, or something else.

Npm and Bower both have pros and cons, and can be used together as @calidion says. In my company we use both because of exactly that reason. We use bower for front-end packages and npm for libraries and utilities, and it's much cleaner than one package.json with all of them.

[j0lvera]

I don't think encouraging only one way to do things is good, is not the nature of the web, people want options. Diversity, even in tools, is good.

Also, I wound't encourage "the community" to use NPM + Webpack/Browserify knowing that next year we are going to have "better and cooler" tools to replace at least two of those. What I would encourage is to test, experiment, and find what tools are right for them and use that, take the decision based on what their experience, not follow blindly what people recommend.

I'm not saying that recommendations are bad, but blindly follow some trend is.

[trusktr]

Sorry guys, I was half-way ranting because I find libraries that continue to rely on globals and need to be loaded with <script> tags which makes maintenance more difficult. I suppose I'm just being hard on that method because ES6 Modules are the solution we should be using instead of global scripts, and ES6 modules are on the verge of becoming a native part of browsers, but already exist in Meteor/Webpack/Browserify/JSPM/etc workflows, so it'd just be awesome if we all moved to those workflows and encouraged everyone to move to ES6 (or at least CommonJS) modules. If this were to happen, then even if those libraries ceased to exist in a year or two, at least the code written for them (ES6 Modules) would be ready for the ES6-module future, which is unlike what happens if we continue to write global scripts shipped through Bower, where those global scripts will continue to be a maintenance problem.

even the smallest project will get hundreds of packages installed.

That's the package's fault though, not NPM's. There's packages on NPM with zero dependencies.

I'm not saying that recommendations are bad, but blindly follow some trend is.

That's true, but the trend I'm encouraging by suggesting Webpack, Browserify, or anything similar to those is really more the trend of using ES6 Modules, which is a huge part of the future of JS.

Choosing to use Bower today is similar to ignoring that ES6 modules are arriving, which is fine since those aren't native yet, but I'm being a stickler and just wishing everyone would jump on that train right now so that the ES6-module future can come quicker.

[sheerun]

@trusktr I'm on my way to responding to you. I partly agree, please be patient :)

[j0lvera]

We need to consider that people learning web development may find NPM and similar hard to assimilate at first, bower helps with being simple and useful in this case.

[sheerun]

@happy-ali Please don't close issues

[SoundBot]

We need to consider that people learning web development may find NPM and similar hard to assimilate at first, bower helps with being simple and useful in this case.

@thinkxl so instead of encouraging them to use best practices you propose to use obsolete techniques? Maybe we should all start using Notepad because it is "being simple"?

I understand that you guys cannot be unbiased as bower maintainers, but at least you should to come up with road map, how to update bower to be aligned with current technologies.

[olegberman]

I don't use Bower anymore for core projects that I'm working on (I use NPM and Webpack instead). Although if I were to create a landing page with jQuery, fancy moving things, parallax backgrounds, and a contact form, (you name it)... then Bower is something that I would use to manage countless jQuery plugins, etc.

@trusktr depending on global state is bad only if that slows down your shipping times or brings in problems for other developers. Otherwise if your project is small enough it doesn't appear to be one. We should not create a problem if it doesn't exist.

Choose tools for your project, don't let the tools define your project.

tl;dr Bower should live.

[j0lvera]

@SoundBot if someone wants to start HTML for the first time, yes I would recommend to use Notepad, once he/she understands what is HTML about, then introduce Sublime Text, and so on.

What you refer to best practices, are often opinionated practices, or best practices for your case. In my experience I find Bower useful with WordPress development, and Webpack for JavaScript development. Developers around me are in a similar situation, just because they don't blog, don't have github profiles, don't have social accounts or whatever, it doesn't mean they don't exist, they are busy writing code.

I don't think that the right answer to this is to tell everyone to use Webpack/Browserify just because someone thinks is the best and the only solution, AND, encourage other projects that he thinks are obsolete (because he doesn't use them) to close.

As long as people still find Bower useful, I think it should be maintained.

[justinfagnani]

@trusktr it's important to note that Bower is still much, much better for frontend development 1) in cases where you really can't support duplicate versions of packages, 2) When you can't support the synchronous, disk-optimized, node module resolution algorithm, or 3) don't want to be required to use build tools to translate web-incompatible JS source to web-compatible source.

1. Includes custom elements, polyfills, large packages, and global CSS. I absolutely never want multiple nested versions of packages, and npm3 will still gladly give me that rather than fail on version conflicts.

2. Includes native ES6 modules. Node is going off on their own, against the capabilities of HTML wrt modules, and so node ES6 modules won't be loadedable by browsers. Bower has a hope of hosting an ecosystem of ES6 modules that import each other via URL and working natively. An npm module that imported dependencies via: import * as _ from '../lodash/lodash.js'; would not actually work in node (at least as planned now, with .mjs extensions: it wouldn't parse as a module, and in a top-level project folder would reach out of the folder).

3. Includes every CommonJS module, which are simply not web-compatible as evidenced by the need for build tools like Browserify and Webpack, or runtime translators like SystemJS, to cross-compile them to something similar to AMD, which actually does work on the web.

I'm not sure what the ultimate solution is, but Bower certainly behaves how I want a package manager for the web to, and it's ecosystem is compatible with the web. I hope it sticks around a while longer.

[mmmeff]

Yeah, bower is great at being a simple front-end package manager for smaller projects where globals are acceptable.

Yeah, npm is a mess when it comes to project setup and building, even though many new best practices are being generated from that side of the fence.

Why not spend your efforts bringing Bower's simplicity to npm instead of maintaining Bower for all eternity? I'm all for giving people options, but most would agree that the javascript community is in dire need of some defragmentation.

[schneidmaster]

Keep in mind that it's not just about JS projects. Bower is also very useful for asset systems that need prebuilt source files but want to handle concatenation and minification themselves, such as Rails (slash rails-assets). I've encountered a not-insignificant number of npm packages that don't even include built + babel-ified assets because they assume that if you're using npm you'll do it yourself.

[vance]

Agree with mmmeff... I'd rather go back to basics and have NPM be more configurable (consistently configurable) instead of three to five inconsistent ways of doing the same thing. It's all ultimately toward the same end: module management and runtime injection, version resolution, backend, frontend and compiling/packaging/minifying/generating... I don't see C# devs using more than one package manager or compiler and don't see them running around complaining about lack of choices... Maybe I'm hanging out with the wrong devs?

[justinfagnani]

@mmmeff what does bower have to do with globals? Bower packages can use web compatible module systems like AMD, System JS and soon native ES6 modules.

[ansuz]

Since we're all here why don't we also rewrite bower in Rust?

[kornelski]

edit: yarn install --flat does exactly what I need, so I don't have a reason to user Bower any more.

---

npm3 + browserify lacks the feature of showing an error when incompatible modules are used together.

At FT we have many components that are at different levels of maturity and maintenance and have a complex matrix of dependencies. We use semver and rely on Bower to automatically enforce that only a minimal and coherent set of dependencies is used in each project.

We have components for some inherently global things such as page's main font, color palette and nav header style, and we like that Bower will refuse to install incompatible set of components.

Please note that for us it's not a technical limitation of being unable to bundle multiple versions of a global component, but a business requirement. Nothing stops us from using modules/namespaces that enable use of last year's button design in this year's form design, but from product quality point of view such mixing is a bug, not a feature. We rely on bower saying "nope, those things don't work together, your page will look like a ransom note, please use consistent set of components". We don't want to ship more than one set of webfonts, even if npm and clever bundling would make it possible.

[kornelski]

edit: yarn is even faster.

---

I used to favor npm over Bower, but npm 3 for me is such a massive step backwards in terms of reliability and speed, that now Bower seems quite stable and fast in comparison.

[capaj]

Having modules and namespaces that make it easy to use last year's button design in this year's form design is a bug to us, not a feature.

@pornel I wish I had these kinds of bugs more often in my codebase.

[Olical]

Dear Bram Moolenaar, I know you've been working on Vim for 28 years, but Neovim has more features than Vim now. So stop working on Vim, please.

Let's apply this logic to Linux distributions, JavaScript UI libraries or web frameworks in any language. Why on Earth would a project deprecate themselves because someone on the internet prefers an alternative?

Just don't use it if you don't want to. I'm surprised this issue is open.

Not everyone uses your exact webpack + npm + babel + standard + "whatever else has been released this week" stack. Bower is okay for some people. I use npm but it is far from perfect.

[joshmanders]

Webpack, babel, etc aside, Bower installs packages. That's it. It does not do anything npm doesn't do. Instead of doing <script src="bower_components/angular/dist/angular.min.js"></script> do <script src="node_modules/angular/dist/angular.min.js"></script>.

Bower truly is irrelevant and an inferior product. Not to mention you need to use npm to install bower already, so why not skip the extra dependency and headache?

[Pierstoval]

1. Deprecate bower, re-think NPM
2. Force it to resolve dependencies properly like Composer does
3. Break all projects using NPM
4. Break the web
5. Endure frontend/nodejs devs committing suicide in groups
6. Enjoy a good Javascript workflow

[ashclarke]

Now:

NPM is 'newer' and 'better', you should use that. Everyone on the old package manager should upgrade.

In 3 4 months:

New Awesome Package Manager is 'newer' and 'better'; you should use that. Everyone on the old package manager should upgrade.

Welcome to JS development. It's safer here.

Edit: Reflect recent events.

[ashclarke]

Also, this is the worst reason for a deprecation.

for the greater good of the Web/JavaScript community as a whole.

There are many companies and users, using bower, who are quite happy with their workflow. The web and the JavaScript community are not affected by this. Why force your "superior" workflow on others if they are happy with what they have?

[Mparaiso]

Bower user here , I strongly disagree with the author of this issue. I don't want to use NPM/Webpack whatever to manage my front-end dependencies. I'm happy with Bower and I'll stick to that. Imagine someone going on Grunt issue tracker and tell the Grunt team "Consider deprecating Grunt in favor of Gulp". That would be extremely arrogant ,and that's how the OP's message feels like. arrogant.

[ansuz]

troll OP is trolling.

everybody stop now.

go outside and enjoy the sun.

plz.

[Pierstoval]

@pedrosanta After more than half a year of this topic, I think everyone have been moving to webpack or something similar 😆

[DaSchTour]

@Pierstoval just a matter of time and webpack will have a "Consider deprecating webpack" issue 🤣
But I really wonder who this everyone is. I'm quite sure there is a silent crowd of developers that don't care about this meta discussion and just use what's best for their current project needs.

[Pierstoval]

I agree, I personally prefer to be stuck with gulp for classic projects, and gulp + browserify when dealing with ES6 browser-side, and everyone has its own preferences

[joshmanders]

How does one move from Bower to Webpack? I can't find the "Install modules" section in Webpack docs.

[graingert]

@joshmanders try to stay on topic please

[joshmanders]

@graingert how am I not on topic? I'm asking a question regarding why people actually think that moving from Bower to Webpack is feasible... They're two separate things. It's like saying "Most people have moved from eating grapes to throwing balloons at squirrels." when talking about what food to eat.

[graingert]

https://webpack.js.org/guides/get-started/

[joshmanders]

You cannot move from Bower to Gulp, or Webpack. Bower is a package manager. Gulp is a task runner. Webpack is a bundler. All 3 are wildly different things and do different things. You can move from Bower to npm. You can move from Bower to Yarn. But you cannot install packages with Webpack or Gulp.

[joshmanders]

@graingert Show me in those docs where you can install say express framework using webpack itself. I'll wait here.

[graingert]

Bower is built as a small step up from pasting URLs from cdns directly into your html, as @pedrosanta bemoans :

Really enjoyed the simplicity of bower and its focus on front-end and on off the shelf, ready to use JS/libs

@Piestoval's reply:

After more than half a year of this topic, I think everyone have been moving to webpack or something similar 😆

This is framing webpack not as a solution for simple off the shelf packaging, but as a tool to go beyond the need for prebuilt libraries

[joshmanders]

@graingert try to stay on topic please

[calidion]

I think this topic should be locked now.
It is meanless to argue if someone should choose one thing from another or force someone to obey someone else's choice.
At least, we are free to choose.

@sheerun

[ashclarke]

@calidion - Completely agree. Just because individual user x uses npm, yarn, webpack, or whatever other tool, doesn't mean there aren't other users and companies that have invested in the use of bower.

[pedrosanta]

@Pierstoval cool. I think I'll go with http://duojs.org. Their heart seems to be in the right place. Cheers!

[ghost]

What is about not node developers? For example .net world? VS supports bower packages out of box...

[joshmanders]

Pretty sure it supports npm too.

[ghost]

@joshmanders

Pretty sure not of out box... For example in my VS it is absent... It is VS2017 with all latest updates.
What I am doing wrong?

[joshmanders]

@HardHub Using Bower.

[cosminnicula]

Guys, what is this suppose to mean on your first page "...psst! While Bower is maintained, we recommend yarn and webpack for new front-end projects!" ?

[graingert]

@trusktr looks like it's time to close this issue!

[capaj]

@graingert I would expect for bower to be deprecated on npm as well using https://docs.npmjs.com/cli/deprecate so that any one who installs it gets the warning too.

[graingert]

@capaj yeah added a PR with that recommendation

[joshmanders]

[pedrosanta]

Still feel like bower leaves a certain void.

So that's it, the project is done for?

[sheerun]

@capaj Good idea, I've included the notice in both readme and npm deprecate

I think I'll close this issue now. Please keep in mind that even I don't have much free time, I'll maintain and keep Bower alive, so all current projects that use Bower, will continue to work.

Not to say I'd block anyone if she/he wanted to to take some extra responsibility for Bower's future (i.e. maintaining/developing it). If you feel like so, please e-mail me at: [email protected]

If you'd like to discuss something else publicly, please open another issue, this one is a mess.