Adding bower.json and uglified dist version #359
Conversation
|
I don't really want to maintain yet another version for another package manager. My suggestion is to just use npm and browserify. |
|
Fair point. TBTH I've barely used Bower since I started using Webpack a few months ago, and given this package is much more likely to be used on something server-side, having Bower is a bit unnecessary. So, good decision. 👍 |
|
@devongovett @Aendrew Even with as popular as bower is these days? I'm going to use this third-party mirror, but it'd be much nicer to have first-party support. |
|
My understanding is that development on Bower has pretty much stopped. Read this: reduxjs/redux#944 (comment). I have no plans for Bower support, and if you are using Bower, I'd recommend moving to npm as soon as you can. |
|
@mattblang Pretty much what @devongovett said. Bower isn't popular any more. Are you using Bower through a Gulp-based build system (I.e., via Yeoman)? Then there's absolutely no reason not to use something like Webpack or Browserify for your build process, and use npm for your dependency management. I've submitted a dozen or so PRs like this, and am now closing any that are open because Bower isn't really necessary any longer (It was brilliant two years ago, but in modern ES2015 module management land, it's way more effort than it's worth). Obligatory link to That Cube Drone Comic. |
|
@Aendrew - a lot of people still use bower, myself included. why not make your library more convenient? |
|
@booleanbetrayal Lots of reasons, not least because Bower development has slowed to a crawl and it adds additional maintenance burden on library maintainers (needing to keep dependencies in bower.json up-to-date, in addition to package.json). It's totally fine if you want to continue using Bower and not improve your practices, but library maintainers shouldn't feel the need to exert any extra effort in order to help you do so. My two cents, anyhow. |
|
In the real world, it's not always possible to refactor every projects'
|
|
Without spending too much more time on this — I'm really lost as to your point. Nobody's asking anybody to refactor anything. All projects that use Bower will continue to work, and so long as Bower doesn't take down their centralised registry, it will be possible to grab the existing dependencies at the version that was referenced when the code was originally created. By this I mean I'll be able to clone one of my old frontend projects later on, do a What's being considered is whether package maintainers should have to include and maintain another dependency graph in their projects, particularly when the package manager that uses it is decreasingly maintained. |
|
Actually, you're talking about introducing an entirely new pipeline for client-side code if your existing pipeline is solely Bower dependent. It is extraneous for the end-user. Seeing as how the Bower is not dead, yet, nor has it officially been announced as such, and considering that most every client-side library out there instructs users to install with Bower, the rush to NPM-only dependency management seems premature and inconsiderate of end-users. There are a thousand different modules to bump versions, so I don't buy the argument of maintenance lift. That's all. |
|
I'm going to close this discussion now. I'm not going to add official Bower support. However, if you would like to maintain a separate repo containing only the pre-built files for Bower, you can do that. |
I ran into PDFKit earlier today and I want to use it as a dependency for a few things, and noticed it didn't have a
bower.json. It's also hard to use withbowerif the only non-browserified distributable version is built in a release. So I addeduglify-jsas a dev dependency and added a few lines to the Makefile that create adistfolder with a minified version in, then added abower.json.Wasn't sure what to use as the contact email, please let me know if I should amend!