@tkrotoff: maybe this solution would be better?

@mdo: please chime in; it is sort of a breaking change but Bower seems to be absolete nowadays, so it would be better if we provided a proper npm way to do things as we discussed in #23557

Asked Twitter to weigh in :D. I'm unsure on overall usage—I don't think Bower ever had install stats like npm does on their packages. Hard to know how used it is.

I vote: "drop it".

Drop it vote!

drop it

Drop it

keep it

If it means Bootstrap having multiple npm packages, I'm all in for dropping bower.

@chyvak1831 I feel like the argument for dropping is there. Do you have an argument for keeping it?

I happen to use Bootstrap via Bower but would be happy to hear of a better way to proceed.

Keep it

Drop it. There's no need for it to exist anymore. It's better for everyone to focus entirely on npm.

Drop it

Drop it like it's hot

Dracarys

Drop it

Drop it. It's been abandoned and practically superseded by npm for a while now.

So @mdo it seems most people are in favor of this. Only concern is VS?

Drop it

drop

Drop

Drop It!

@XhmikosR @cvrebert About bower.json @$% Not a Bower package... ^&* like in Bootlint can you explain how this works?

@tkrotoff That's just blatantly invalid JSON to make it clear that Bootlint deliberately doesn't support Bower. If there wasn't a bower.json, I'm sure we'd get pull requests adding one or issues asking for one.

Keep it.

keep it

Drop it npm is better.

Drop it.

There's so many fundamental issues with bower that, even if it causes breakage in cases, even for myself, I'd vote drop it. We'll fix those cases and move the whole ecosystem to brighter future with npm catering to all our packaging needs. If twbs sets this example I'm sure many will follow suit 👍❤️

@XhmikosR @cvrebert I've git rewrote history and kept bower.json with @$% Not a Bower package... ^&* in it.

I vote drop.

Bower is kind of dead to me nowadays.

Keep. I still use bower.

I'd decide based on the workload it creates to still support Bower. It's always nice to keep backwards compatibility, however if it involves some serious work on your end and is possibly blocking a more modular approach (which could likely be achieved with Bower as well?!) I'd say go with npm/yarn instead.

Bootstrap 3 will continue to be available with Bower. This only applies to v4. If you have an old project, this changes nothing.
If you create or upgrade a project to cutting edge Bootstrap 4, it does not make sense to rely on a deprecated tool for your project.

And Bower is deprecated, really:

• Bower website displays the deprecation notice
• same for the README:

• and even when installing Bower:

$ npm install bower
npm WARN deprecated bower@1.8.0: ..psst! While Bower is maintained,
we recommend Yarn and Webpack for *new* front-end projects!
Yarn's advantage is security and reliability,
and Webpack's is support for both CommonJS and AMD projects.
Currently there's no migration path,
but please help to create it: https://github.com/bower/bower/issues/2467

Does dropping Bower also mean that all the compiled code in dist/ and js/dist/ can be removed and ignored from the repo or is there still a reason to include it?

We use our dist files for our documentation too, so they'll stay if we drop Bower

Bootstrap 3 will continue to be available with Bower. This only applies to v4. If you have an old project, this changes nothing.

As we're also advising people to use yarn/webpack for new projects, this sounds like a neat solution. 👯

I vote for keeping Bower support.

Please drop it.

Drop it.