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.

[thinkxl]

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

[thinkxl]

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.

[thinkxl]

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

[capaj]

@Mparaiso @cmmata I don't think comparing to grunt is relevant here. Package managers are much more important tools than CLI runners, because without packages, node.js/frontend development is almost impossible. Whereas without CLI runner I can very easily manage-in fact in most of the projects I do, there is no need for grunt/gulp whatever.

If NPM would have to compete with lots of other variants, node.js ecosystem would be severely hampered as a result. It is certainly very beneficial if you can have those infrastructural questions resolved in unified/standard way. On the frontend, bower is probably one of the most successful attempt at resolving package management. Problem is, it didn't go far enough. It stopped evolving.

IMHO it comes down to these two questions:

1. Should it be deprecated? No.
2. Should it be shown as a primary frontend package manager to newbies? No, there are better alternatives. Namely NPM or JSPM.

[kornelski]

@capaj I've rewritten that sentence in case I wasn't clear that design inconsistencies are not desirable.

[Ashtonian]

Oh you poor sheltered children, you don't know what package management hell truly is. Just be glad you have options and are having to discuss which of the two awesome platforms is more awesome.

See Nuget...

/end drunken old cranky man rant

[sheerun]

If someone wonders why this issue is so popular, thanks reddit :)

I've read all the comments here and there and that are my thoughts:

• JS community doesn't benefit from two package ecosystems (i.e. one network of packages made with bower.json dependencies and second one made with package.json dependencies)
  • It is a burden for package authors to maintain both bower.json and package.json
  • bower.json and package.json can easily get out of sync
  • lack of preferred module system for bower makes bower dependency depth really shallow
• JS community could benefit from two package managers (as long as they promote the same package ecosystem, i.e. the one created by package.json dependencies)
  • It promotes diversity and healthy competition
  • Allow for domain-specific focus; while npm focuses on node ecosystem and CommonJS, bower could focus on front-end ecosystem and ES6 modules)
  • Bower can bring added value to npm, for example by allowing pluggable resolvers

There are two primary kinds of bower users:

• Application developers, that want to bring modules from different sources to their projects
• Module developers that use bower as a tool for developing and managing their modules

The momentum in JavaScript community is pretty clear: module developers increasingly prefer to use NPM, as it primary gateway of npm package ecosystem. Bower's one just isn't modular enough.

While I feel we're forcing Bower onto module developers, we don't do it for application developers. They use bower because it gives them nice and stable tool to develop their projects.

So while I don't agree we should "deprecate bower", I think we should deprecate current package ecosystem of bower. In particular we should take steps to:

• Suport application developers and:
  • Ensure their current projects continue to work with Bower
  • Release bower version that makes it more easy to migrate to npm ecosystem
  • Preserve current bower functionality
    • Being secure by preventing attacks like typosquatting
    • Support for subversion, mercurial, and pluggable resolvers
    • Allowing for installs directly from source repositories, also without package.json
  • Allow them to easily install modules from npm ecosystem
  • Embrace ES6 modules, enforcable flat dependencies, and easier tree shaking
• Support module developers and:
  • Encourage them to focus on npm ecosystem, and package.json
  • Allow to remove bower.json from their repositories, as well as precompiled files
  • Encorage to use ES6 modules, as they are cornerstone of modern JS development
    • There's proposal to introduce .mjs extension in node ecosystem
    • There's also proposal to add "module" entry in package.json
    • There's also third solution I'm thinking of and I'll share it soon

Let's discuss. I'll try to propose some concrete steps to achieve both goals 😅

[calidion]

@sheerun
I think otherwise.
Bower and NPM may use the same tool base, where npm defaults to nested and bower defaults to flat, but should maintain different ecosystems while they are two different things.
And I am both module & application developer.

[sheerun]

We could still default to flat, while achieving single module network, instead of bower-npm dichotomy.

EDIT: There's discord chat to discuss as well.

[justinfagnani]

The problem is that npm modules would need to be rewritten for the web. This might be doable for a large enough portion of the packages, but certainly there will be a lot of modules that don't work.

[herrstucki]

It's perfectly possible to publish "frontend" modules on npm. Many npm packages provide UMD builds (or CSS, SCSS, binaries, etc). So I'm not sure why people insist that Bower's inherently better for that. Case in point: https://npmcdn.com

One of the key differences is that npm's registry stores a complete immutable package for each published version, while Bower points to Git repos and relies on tags for versioning. That way, Bower places the burden to keep versions consistent and to keep prebuilt files in the repo on each package author. To me, that makes Bower much less attractive to authors (and to users, because you can never know if your bower install will still install the same things in a year).

That said, competition and diversity are always better than a monoculture.

[vance]

Ironic or appropriate depending on how you look at it considering the timing relative to posting on this thread last night. Just this morning Bower barfs my CI environment because one of Bower's 264 dependencies can't resolve a file. [good thing I keep a repository copy of dependencies laying around] I use bower but wish it never existed. There's literally a dependency in there that adds http:// to the front of a string.

[nicodmf]

I think npm and bower aren't used by same developpers. As now, npm is more for totally node.js development and don't care about project with other technologies. Bower is more open and agnostic about the server technology.

I love ES6 too, but the worflow proposed by npm doesn't feat my requirements. I don't want use express or other node framework, i don't want download 300 packages to just make the react frontend of my application.

I prefer bower for many use case and think that even if bower and npm talk about javascript librairies (and css/html framework too) they aren't use for the same purpose. Bower permit a better separation and communication between frontend and backend developpers. Node.js is a good language but other frameworks are better in many cases and i prefer a tool that don't anticipate my server technology.

[joshmanders]

I think npm and bower aren't used by same developpers. As now, npm is more for totally node.js development and don't care about project with other technologies. Bower is more open and agnostic about the server technology.

npm doesn't care about what server technology you use either.

I love ES6 too, but the worflow proposed by npm doesn't feat my requirements.

npm does not propose ES6, ES6 is the current version of the ECMAScript standard, whether you use bower or npm doesn't matter in this. The developers of the packages you use decide if the packages you get are using up-to-date features or not.

I don't want use express or other node framework, i don't want download 300 packages to just make the react frontend of my application.

Then don't? Not sure what npm/bower has to do with this.

I prefer bower for many use case and think that even if bower and npm talk about javascript librairies (and css/html framework too) they aren't use for the same purpose. Bower permit a better separation and communication between frontend and backend developpers. Node.js is a good language but other frameworks are better in many cases and i prefer a tool that don't anticipate my server technology.

Once again, npm doesn't dictate any of the server software you use.

If you use bower, you already have npm installed.

[nicodmf]

I'm not agree, the ecosystem make choices for his community and the npm community is primarily a node server community. And surelly this is better as this, a developper think his system as an unique piece when he manage his dependencies (and develop module too).

If you compare with other system :

• yum/apt
• pip
• gem
• composer

All of there tried to manage all packages. Npm actually make the same, but the question is : do we want an unique package managers to manage two differents systems ?

So for me two package managers seems a better approach.

(I know what is es6 and prefer use class as function, for me before es6, javascript wasn't really a complete language, even if many excellents works - as bower is - with node could demonstrate that a good language isn't just a classical syntax).

[joshmanders]

Every package that is on bower, is on npm. You can cut bower out of the equation and still do exactly what you did before, only difference is you swap bower_components out of the path for node_modules

[nicodmf]

That's not the only difference. You can't think modules for front as module for back and naturally back nodejs dev will try to optimise and simplify the workflow with closed technics.

And if npm make the choice to deliver all cases, the tool could be less powerfull for his primary case : manage nodejs dependencies.

[Pierstoval]

As discussed many times, using a package manager to install other package managers is a pain and makes no proper sense at all.

Or just create a package manager that do not depend on npm then, else it's too cumbersome.

[nicodmf]

not wrong, but with html/css/js, i don't see how to create a command, it's an obligation to use another language with command line support.

[Pierstoval]

If you have to use nodejs for your frontend workflow, then just use one of the tons of workflows that exist (gulp, grunt or anything), and install your frontend dependencies as node_modules, and your workflow is here to compile your frontend assets in your public directory 😕

[nicodmf]

i know and this is near i said :

• two cases, one ring

[mmmeff]

@nicodmf

You can't think modules for front as module for back

I beg to differ. I've been using npm to build a universal javascript application in React for the past 6 months. My modules are used on both the front-end and the back-end to achieve full isomorphism through server-side rendering.

Developers have the choice to build isomorphic components or simple front-end or back-end components. It's a singular ecosystem that serves all needs. A package is a package is a package.

.

I think npm and bower aren't used by same developpers.

You're right, all the good ones have moved on to strictly npm-centric solutions

.

As now, npm is more for totally node.js development and don't care about project with other technologies.

This is simply wrong

[faceleg]

You're right, all the good ones have moved on to strictly npm-centric solutions

@mmmeff no need for insults thanks.

[tnga]

If bower steel have more than 14000 star here on github and is generally on top 5 of npm weekly downloaded packages, it isn't for nothing. Web frontend development on it base, hardly depends on xml/html, css, javascript languages. However, with web backend development, we have many choice of languages like php, java, c, c++, python, ruby, shell, etc. javaScript is one of recent languages that offers that possibility (thank to nodejs); but it isn't the only one or the best choice for as some people think. It actual community is like a child which is too excited about new possibilities it have discovered and forget it experimented others sisters languages's communities.

bower seems to have more visibility than npm here because it easily complain with previous enumerated languages's developers communities.

a project with bower_components:
|--- bower_components/ only for frontend purpose
|--- |--- some_pkg/
|--- |--- |--- dist/ for frontend
|--- |--- |--- src/ if provided, generally only depends of preprocessor or frontend stuff
|--- here can be php or ruby or python or nodejs/javaScript ... hack for backend stuff

a project with node_modules:
|--- node_modules/ frontend and backend bazar
|--- |--- some_modules/
|--- |--- |--- dist/ for frontend or backend ??? it will "maybe" depends of the module
|--- |--- |--- src/ always provided. for backend or frontend ??? it depends of developer usage
|--- |--- |--- However non-nodejs developer will not need backend features of the module since,
|--- |--- |--- his chosen language API surely provide what it will need (io, socket, stream, ...)
|--- that said, unless to like to have thousands of small files that isn't useful in your project,
|--- this way is more benefit for nodejs/javaScript developer

Therefore people who starred bower repository come from many languages's commities than people who starred npm (mostly a nodejs/javaScript developers). That can explain why npm is only more than 9000 star here on github.

So what? Maybe tomorrow someone will consider to deprecate Rails or Django or Lavarel or Symphony just because to

encourage people to move to them for the greater good of the Web/JavaScript community as a whole and to be ready for the ES6-module future.

As @herrstucki said

competition and diversity are always better than a monoculture.

[Pierstoval]

Rails and Django are brought down slowly, because of the popularity of javascript. But Symfony or Laravel probably won't because of the fact that their performances are very much comparable to JS now, thanks to PHP7 and focusing on good code (can't say much more about Laravel because I don't like it).

But IMO the problem with bower is that it's better in resolving dependencies (much much lighter actually), but it depends on #$£%µ NPM...

[tnga]

I was also puzzled about the fact that bower depends on npm. That kind of affirmation is why we have bowerphp just because we done want that our project depends on another (competitor) language. Many developers like SASS, but some of them was turning around because they was waiting for it compiler tools's port to javascript due of same previous reason. However, when gaining experience with project development, this question open to me new perspective: "why should i always write all my project from scratch if there are some excellent module that someone take time to write and that can help me to go ahead quickly?". like bowerphp, there is possibilities to have a stand alone bower that don't depend on npm to be installed; but i think is better to have something like npm install for that than apt-get or yum or brew, ...

[calidion]

@tnga
A very good idea.
bower should be independent from node or npm.
The idea of seamless integration with php, python, go, java, ruby etc. is great.

[eman1986]

I love bower, it has made managing my front-end libraries much more manageable.

I'd looked at switching to npm, but it seems like a major hassle as you'll need to find a way to compile it for web-use, maybe I'm missing something but unless npm can do what bower does for my needs, I have no wish to leave bower.

btw, if someone can point me a way to use npm just like bower, I'll take a peek, but otherwise I'm not interested in trying to fix legacy code to be modular just yet.

[joshmanders]

@eman1985

btw, if someone can point me a way to use npm just like bower, I'll take a peek, but otherwise I'm not interested in trying to fix legacy code to be modular just yet.

Currently you run bower install jquery and to use jQuery you now have to put the following tag on your page:

<script src="bower_components/jquery/dist/jquery.min.js"></script>

Instead, run npm install jquery and put the following tag on your page:

<script src="node_modules/jquery/dist/jquery.min.js"></script>

Congratulations you just removed an extra dependency from your workflow.

[eman1986]

@joshmanders I do more than that, I also run a gulp task that gets just the dist files so I'm not deploying a bunch of junk and waste space on my prod server (the node-modules folder is ungodly huge).

I'm currently using bower-installer, but sadly that tool is on life support so if such a solution existed on npm, I may feel more inclined to look at npm as an option as I am interested in it.

[mmmeff]

@eman1986

Webpack should replace your gulp/bower build pipeline. It allows for modular imports of npm modules, plenty of which are either front-end or universal, and will use tree-shaking to cull any "junk" from your final production build artifact.

My point being that it's no more complex than what you're already doing with gulp, and switching to npm really is not as much of a hassle as you may think.

[eman1986]

I've looked at webpack too, but I haven't found a good enough resource on how to use it, I'm open to a good article on it.

[calidion]

@graingert the truth is that npm maybe replaced by yarn:)

[cmmata]

@calidion @graingert and in a few (days / weeks / months), there will be another super-pretty-cool package tons of times better than yarn and npm. And everybody should switch to the new package.

[DaSchTour]

There are over 500 000 votes against deprecation every week. I guess this issue should be closed as long as it is used by so many people.

[graingert]

@cmmata why is this issue even open?

[julmot]

@DaSchTour

There are over 500 000 votes against deprecation every week.

Where?

[graingert]

@julmot I think @DaSchTour refers to active users

[sheerun]

We'll consider "deprecating" Bower CLI if Yarn achieves feature parity with it:

https://bower.io/blog/2016/using-bower-with-yarn/

Deprecating bower module ecosystem in lieu of npm's can also happen if someone organizes it in a way so backward-compatibilty is maintained and we provide a way for developers to gradually migrate. One idea I don't have currently time or money to realize is:

1. Enhance Bower/Yarn, so it allows to install CommonJS npm modules and transocmpile them to UMD post-install, and place in bower_components directory
2. Encourage application authors to upgrade Bower/Yarn and gradually replace bower dependencies with npm dependencies (that are optionally transcompiled as a part of step 1)
3. Freeze current bower registry
4. Mirror all existing packages and their repositories, pointing registry entries to mirrored copies
5. Encourage package authors to remove bower.json from repositories

[graingert]

@sheerun steps 3 and 4 can be done with scoped packages

[sheerun]

@graingert 3. and 4. are needed only to maintain backward compatibility, so it requires that mirrored packages are git repositories, not scoped npm packages. To be honest, I have no idea how to achieve it, and it most likely it would require cooperation with Github iteself, and provide Bower a "snapshot" feature, so we can point all package enpoints to something like https://bower.github.com/xxx/yyy.git that behaves like normal repository, but is frozen in time.

There's yet another (maybe even better) option: if someone removes bower.json from his repository, fork working version to bower organization and automatically replace url in registry with fork.

[graingert]

@sheerun deprecation doesn't mean abandoning existing users, just request that new users use npm/yarn instead.

[sheerun]

As I said, I'd really like to point to Yarn, but it's currently unusable as Bower alternative.

[graingert]

@sheerun no, I mean point people at npm/Yarn for managing npm packages

[graingert]

@sheerun I'm just trying to work out what goals the bower project has, for the installer and bower.io.

[sheerun]

@graingert We could do it as well.. It's a good idea to present available options. If someone here would like to prepare a blogpost on Bower blog that describes npm and yarn as Bower alternatives (and their advantages), we could publish it, and maybe even link from homepage.

EDIT: I'd also put focus on blogpost how npm module ecosystem is better than Bower's

[ashclarke]

Regarding Yarn...

Called it. Only ~1 month out.

#2298 (comment)

I'll forgive those who gave a thumbs-down.

[calidion]

@sheerun I would agree on the unification of version management and packaging rules in the further, but not on the directory combination and their respective package descriptions.
I would prefer that bower_components and node_modules, package.json and bower.json remain as they are now.

[graingert]

EDIT: I'd also put focus on blogpost how npm module ecosystem is better than Bower's

Is this something that the bower project wants to publish?

[calidion]

in my option, npm is not very good at version management.
and npm3 is worse in doing this.
due to nodejs restriction, npm cannot update its rule alone.
but bower has no such restriction, it may not be a good choice to simply switch to npm or yarn.

[sheerun]

@calidion I don't mean any changes to bower_components, node_modules, bower.json or package.json. Just present Bower users with alternative options, and describe their advantages. Also encourage to look into npm modules and allow to install npm modules with bower (to bower_components). Please understand that npm CLI is not the same as npm/commonjs modules.

@graingert I see no problem with it, if it's true. The problem with Bower components is well described here: https://medium.com/@trek/last-week-i-had-a-small-meltdown-on-twitter-about-npms-future-plans-around-front-end-packaging-b424dd8d367a#.v24fnlsmu

[Pierstoval]

Why, for the sake of development, no one takes example from Composer in the PHP ecosystem?

Composer has proven in a few years its capabilities and that it is very good in managing both versions constraints, compatibility, semantic versioning, security (ssl & etc.), cache, source vs dist, custom repositories, extra, scripts, etc.
Everything (ok, I'm extrapolating a bit) is cool in Composer, and we almost never hear anything about Composer, and yet it's still the best package manager for PHP (and has pretty much replaced PECL, even if PECL is good for PHP extensions, not only "packages", but it's another subject).

PHP is underrated by tons of developers today, but its community has been driving a bad language to the right direction, with awesome standards and a great package manager. I don't get why Node.JS (which is brand new compared to PHP 😛) doesn't take example from others by doing something that could be both similar & better (like Twig does with python's Jinja templating engine, for example).

As you said @ashclarke , you predicted well: in the Javascript world, anything "brand new & innovative" pretends to be a replacement for anything else that is older.

But this is not how programming works, and this is precisely true in the simple fact that C (1972), Bash (1989) and Vim (1991) are still alive today.

[graingert]

Bower support has been removed from yarn: yarnpkg/yarn#1441

Because:

Bower is on it's way out and we shouldn't be supporting it

and

I honestly think this was a great thing to do, not only for Yarn but for the community at large. Bower is not only dying, it cannot die soon enough. This would resolve a plethora of issues and save a ton of resources around double package maintenance, inconsistencies etc.

@benmann You should probably take down your blog post, or at least edit it to be up to date with the current state of bower in yarn

[Zearin]

@benmann You should probably take down your blog post, or at least edit it to be up to date with the current state of bower in yarn

Please be civil. There’s no reason to aggressively hammer the bower maintainers (or anybody) into submission.

[graingert]

@Zearin you be civil - your false accusation is rude. I wasn't being rude: the blog post is recommending bower users try yarn because of its bower compatibility. The blog post should be updated to address the fact that yarn has dropped bower

[sheerun]

@graingert Thanks for suggestion. I've updated blogpost to mention it

[sheerun]

Here's my proposal to deprecate server-side part of Bower and move it to GitHub: #2388

[pedrosanta]

Just to add I find this thread really funny and interesting - in several ways. Really enjoyed the simplicity of bower and its focus on front-end and on off the shelf, ready to use JS/libs - also didn't exactly forced any build or bundling, and also didn't introduce too much setup/bootstrap overload when one wanted to hash a quick prototype. Oh well.

Will welcome any forks or new tools with the same gist.

Cheers y'all!

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

[hardhub]

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

[joshmanders]

Pretty sure it supports npm too.

[hardhub]

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

[cosmin-nicula]

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: sheerun@sher.pl

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