Consider deprecating Bower.
trusktr opened this issue · comments
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.
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.
@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.
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.
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.
@trusktr I'm on my way to responding to you. I partly agree, please be patient :)
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.
@happy-ali Please don't close issues
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.
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.
@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.
@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.
-
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.
-
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.mjsextensions: it wouldn't parse as a module, and in a top-level project folder would reach out of the folder). -
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.
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.
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.
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?
@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.
Since we're all here why don't we also rewrite bower in Rust?
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.
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.
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.
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.
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?
- Deprecate bower, re-think NPM
- Force it to resolve dependencies properly like Composer does
- Break all projects using NPM
- Break the web
- Endure frontend/nodejs devs committing suicide in groups
- Enjoy a good Javascript workflow
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.
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?
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.
troll OP is trolling.
everybody stop now.
go outside and enjoy the sun.
plz.
@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:
- Should it be deprecated? No.
- Should it be shown as a primary frontend package manager to newbies? No, there are better alternatives. Namely NPM or JSPM.
@capaj I've rewritten that sentence in case I wasn't clear that design inconsistencies are not desirable.
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
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
.mjsextension 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
- There's proposal to introduce
Let's discuss. I'll try to propose some concrete steps to achieve both goals 😅
@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.
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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 😕
i know and this is near i said :
- two cases, one ring
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
You're right, all the good ones have moved on to strictly npm-centric solutions
@mmmeff no need for insults thanks.
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.
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...
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, ...
@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.
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.
@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.
@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.
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.
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.
Here you go, this is my gulp task for building my frontend code using webpack.
https://gist.github.com/joshmanders/1c69290e7c6466e2960cb1e995faaefb
What this is doing is any module you import it checks to see if it is in your app directory or node_modules directory, if it's in app it gets bundled in app.js otherwise vendors.js
It also does babel transpiling and that. So now all I need to do is npm install my dependencies, and import $ from 'jquery' and now my module has $('.selector')
https://egghead.io/lessons/javascript-intro-to-webpack
Good video that shows the concepts without being too opinionated on module syntax or anything like that
thanks for the video link, based on what I seen, that may not a good idea for existing code, least not in the immediate need. but new code webpack sounds awesome and I'll definitely be looking into using it at that time. for now on my legacy code, I may just stay with bower as that's the best solution or switch to npm, which would be a step in the right direction of reducing my workflow without having to go full modular just yet.
yes, I'm saying that. at this moment I'm sticking with bower with projects that's already using it but new projects I'll be willing to dive into using webpack to streamline that process.
We worked out a third proposal of ES6 module detection that boils down to at least one export in file:
https://github.com/bmeck/UnambiguousJavaScriptGrammar/blob/master/README.md
This is possibly the path we'll go with bower, but still waiting for consensus.
i don't find in npm the bower_rc option to choice my path : "directory" : "web/vendor", is it exists ? Without that i prefer pretty much more bower.
this may help you with that question:
http://stackoverflow.com/questions/6685892/how-do-i-fix-npms-global-location
@sheerun For what it's worth I very much enjoy the simplicity of how bower is just a way to get certain static files onto a system. That is all I want really.
Web development doesn't have to be complex, the browser is designed to "just work" ;) I want to prototype quickly and making a few script tags in my document is no biggie for me... so bower is great!
I really like to just specify {"name":"usename/projectname"} in bower.json and not worry about a bower.json file or git tag being available. It would be really great to be able to do bower install --save userName/repoName! Just assume name is repoName.
Web development doesn't have to be complex, the browser is designed to "just work" ;) I want to prototype quickly and making a few script tags in my document is no biggie for me... so bower is great!
You can do that with npm too.
I really like to just specify {"name":"usename/projectname"} in bower.json and not worry about a bower.json file or git tag being available. It would be really great to be able to do bower install --save userName/repoName! Just assume name is repoName.
npm allows you to do that, and you can npm install --save username/reponame.
Thanks @joshmanders ! I guess one downside of how npm and bower currently do this is that it just grabs the package from github's servers and there isn't really an integrity check going on. I would appreciate a service that was separate from github which could store/supply a hashsum of the tarball for any given commit.
(I also really like that bower let's you specify the name of the output directory, with npm you gotta use node_modules)
For what it's worth I very much enjoy the simplicity of how bower is just a way to get certain static files onto a system. That is all I want really.
I totally agree with that. Furthermore I personally don't like npm as it is more than that. We need to publish on a separate service, tagging is not enough. And we have very limited rights, e.g. can't delete a release. Also I don't like the feature to add stars to a package on npm, as this is already implemented in GitHub and seems to be quite unnecessary.
Overall, I like that bower is that simple and can't live without :-)
The only alternative I see here is to use the npm GitHub syntax. However, as this currently doesn't allow to load specific versions (only commits), this isn't a great solution.
I think one thing to call into question with both bower and npm is the "single name" scheme for referring to packages on the system. I don't think it is very sustainable. Already we see cases where companies are litigating for naming rights within NPM.
At the very least GitHub has been at this for a while and has a very clear process... https://help.github.com/articles/dmca-takedown-policy/ npm's is a bit more fuzzy... https://www.npmjs.com/policies/disputes . Either way... with a single name scheme at any moment your clever name could be in the way of someone else's legal trademark getting a nice spot in the system.
A package manager does not need to be much more than service which points the client at GitHub's API. Bower itself could probably loose the current registry and just act as a middle man to ensure the integrity of github(or whatever clone)'s tarball downloads.
Just my 2 cents!
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.
do more than that, I also run a gulp task that gets just the dist files
Something simple like a polyfill for you means a scavenge hunt through github repos, hopefully it's an old es5 blob or UMD, or you're out of luck. You procede to manual includes in fixed order, possibly changing your gulp tasks, dirty replacing your html files, making copy's for your prod-output, etc., etc., etc. That is a hassle.
You spend a day understanding webpack and npm and all of that will be over.
one thing I'm a tad turned off is that it adds more files for me to deploy. I guess in the long run it is a more efficient running website, but means more I have to upload to my prod & dev servers
How does it add more files to deploy? Webpack? Actually no, it doesn't. Gulp concating your files is not a good thing to do, it's messy and can get out of order. Including individual script tags in your page is messy and adds tons more files to your deploy... Webpack... Webpack does not. it builds a bundle. A single file, that using proper deduping, tree shaking and minification makes your build better, leaner and faster.
I mean, for example, I have an admin portion of my site and it has 25 "pages", so for each css and js file I use thats going to create a js & css file for each of those pages. I normally just load the vendor files I need and inline my javascript (sometimes I make a dedicated file for it if the js code is very in depth)
I guess you could just make a js file for all admin code but then I'm loading stuff I may not need 100% of the time. I like the concept of webpack and trying to read up on it, but so far I run into little items like that that's making me feel uncomfortable.
You would use chunking in Webpack to achieve that. That allows you to have a vendors.js, app.js, admin.js and common.js file built out of all your code. vendors.js is all the stuff you npm install, app.js is the code needed to run your app, and admin.js is all the code needed to run your admin, common.js would be the shared code between app.js and admin.js. All this can be managed by Webpack so you don't have to think about it.
@drcmda Perhaps bower could turn npm modules into UMD modules automagically on download ;)
@joshmanders could you direct me to some reading on that, because that sounds really ideal and what I'm really looking for.
What attracts me the most about bower is the separation of concerns. And the simplicity of use, but npm seems to be on par.
My current project's bower_components holds ~50 dirs (~50mb) and my node_modules holds around ~700 dirs (~100mb).
Maybe I'm looking at it the wrong way, but it Feels Right™ to have a .json and a directory dedicated to the front end stuff alone. Where it's actually feasible looking at it, to go through your front end stuff.
@trusktr
you seem to have package management confused with asset quality determination and control.
I'll help clarify.
Package managers are used to retrieve and install assets like javascript files, image files, C source code files etc..
Package managers are hence concerned with what needs what, where to get what and where to put it.
Asset quality determination and control relates to actions and measures used to determine and set measures and methods of measure pertaining to the quality of a thing, here digital assets of various kinds.
Quality determination and control is hence concerned not with where things are or what needs what but rather the state of the various qualties of the asset itself.
Simply put:
package manager : what where regardless of quality
quality manager : quality of the what regardless of where.
Hope that helps you better decide on which package manager to use.
I personally prefer Bower. Just a better quality pm.
(Halfway through reading this long thread. Just wanted to pop in a quick comment before I read through to completion!)
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.
There is a little-known command: npm dedupe (or the alias npm ddp). Basically, it flattens out the hierarchy under node_modules.
It is not perfect; there is no guarantee for perfect flatness. If a package cannot be successfully flattened because of a conflict with another, then that part of the hierarchy will remain.
(I know this is aside to the greater issues being discussed. I just think this command has largely flown under the radar…and think that’s a shame, because I find it pretty useful.)
(…Okay, back to reading the thread!)
(I got just a couple posts further before I had to chime in again.)
I think npm and bower aren't used by same developpers.
Not quite.
By the time I read this, the point had already been made many times in this thread.
NPM developers and Bower developers are a Venn Diagram. It’s easy to get lost in all the details being discussed here, but this is a simple concept to understand:
Some Bower devs have nothing in common with NPM devs, and vice-versa.
(Okay, back to reading this thread…)
Better to extend system package managers to use the package formats. Better still if the script providers used a universal package format, a variety of repos, possibly those allready used by system package mngrs. A lot more people could use the scripts this way and the current system repos allready afford commercializing the scripts/apps if wanted.
In short make a clean seperation instead of forcing a package nanager and single script engine on every ones machine with the scripts.
People might better appreciate the work not to mention not be obstructed from using the work due to bower - npm.debates and issues.
With projects like Angular and lodash moving away from bower, I think this should be re-visited.
With projects like Angular and lodash moving away from bower, I think this should be re-visited.
Wow, really? So, if a few popular packages started “moving away” from Homebrew, you’d want to shut that package manager down, too?
I still think there is discussion worth having here, but I find the reasoning above unsettling. Sure, it’s true that a package manager is only as good as the packages it has to offer.
(Actually, I think there’s more to it just that. I love Python, but hate pip, for one…but I digress!)
The point is, a package manager should die when its user base dies—not based on the presence or absence of specific projects. If the user base abandons the package manager if those projects go away, then that’s one thing. But when one or two projects start have the power to decide which package managers live or die, then I think we have unwittingly sailed into some truly dangerous waters.
I think the fact that this issue is even open says a lot about the project.
@graingert the truth is that npm maybe replaced by yarn:)
@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.
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.
@cmmata why is this issue even open?
@julmot I think @DaSchTour refers to active users
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:
- Enhance Bower/Yarn, so it allows to install CommonJS npm modules and transocmpile them to UMD post-install, and place in bower_components directory
- 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)
- Freeze current bower registry
- Mirror all existing packages and their repositories, pointing registry entries to mirrored copies
- Encourage package authors to remove bower.json from repositories
@sheerun steps 3 and 4 can be done with scoped packages
@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.
@sheerun deprecation doesn't mean abandoning existing users, just request that new users use npm/yarn instead.
As I said, I'd really like to point to Yarn, but it's currently unusable as Bower alternative.
@sheerun no, I mean point people at npm/Yarn for managing npm packages
@sheerun I'm just trying to work out what goals the bower project has, for the installer and bower.io.
@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
Regarding Yarn...
Called it. Only ~1 month out.
I'll forgive those who gave a thumbs-down.