bower: Unexpected deprecation notice
Output of bower -v && npm -v && node -v:
1.8.0
3.10.3
v6.3.1
Additional environment details (proxy, private registry, etc.): N/A
Steps to reproduce the issue:
git clone git@github.com:cla-assistant/cla-assistant.git && (cd cla-assistant && npm i)
Describe the results you received:
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 we hope you'll help us figure out one.
Describe the results you expected: No warning. No statement of recommendation for Yarn or Webpack.
Additional information: You’re stating public support for a package management tool with an unproven track record which is currently in development with close to 800 open issues. I question the merits behind this direction, especially for a package manager which downloads unexpected dependencies and closes issues before they’re resolved. I have feelings about Webpack. But let’s start with Yarn because Webpack at least is not still sitting on a point release.
Furthermore, if Bower is no longer a thing the candle which was lit for front-end package managers becomes absolved by an ecosystem (Node) which does not nor will have anytime soon support for ES6 modules - the future of how we will build JavaScript for the browser.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 17 (2 by maintainers)
Commits related to this issue
- build($package): drop support for bower, they've jumped the shark https://github.com/bower/bower/issues/2464 — committed to vhscom/fetch-inject by vhscom 7 years ago
- build($package): drop support for bower, they've jumped the shark https://github.com/bower/bower/issues/2464 — committed to vhscom/fetch-inject by vhscom 7 years ago
- build($package): drop support for bower, they've jumped the shark https://github.com/bower/bower/issues/2464 — committed to vhscom/fetch-inject by vhscom 7 years ago
bower died since 2013 just npm install your stuff
Like 95% of bower installable things also have a
package.jsonfile right there, so the install process wouldn’t really be that different you may have to change some paths on your compilations tasks but thats about it 😄FWIW I’m using NPM to manage front-end dependencies for a theme I created for Hugo. I kind of like the idea of not having to manage a
bower.json(originally calledpackage.json, before they switched) in addition to my other package manifest. I’m dropping support for bower in myfetch-injectmodule. Bower had a good vision, but NPM had the momentum.I still disagree with promoting other tools. But I’m not going to hold an issue hostage on a deprecated tool. Thanks for all Bower has accomplished. May it go quietly into the night. Cheers.
i do not understand the reason for recommending some other tools for different use cases. Yarn is supposed to be better npm, as far as i understand, but npm is not an easy to use front end package manager, so is yarn. Also yarn dropped bower support last year. even composer is better for front end dependencies than yarn or webpack.
@Grinderofl lol you do understand this is open source and no one owes you anything right? if you want control build it yourself, or make a fork 😄
im grateful for bower even though I don’t use it anymore
So I just now had to add a --silent flag to the npm part of the build scripts get an unmodified project to build on the build server because out of bloody nowhere, a random warning on top of the build log appeared which caused the entire process to be killed! Now we won’t be notified if there’s an actual error in the npm part of build 😄
Was it really so difficult to make a new version and put the message there instead? Nope, it had to be added on top of every single version that I tried down to 1.1.0. Cheers for another reason to use JS-based tools even less…
Node and browser are two very different things with very different goals. Backwards compatibility being one of them. Otherwise we wouldn’t’ve had 17 different wrapper types prior to ES6. As far as I know Bower also has never forcefully removed a developers package (
kik) and given it to a corporation. If everyone used the same tools there would be no choice and, hence, there would be little innovation. I stand firm on this issue.