Added package.json #380
Added package.json #380
Conversation
|
@callumacrae this package is already available on bower. Since this isn't a Node.js package, why should we publish it on NPM as well? |
|
Browserify uses npm EDIT: To clarify, I can run |
|
I have some serious mixed feelings about dealing with another package manager around here. I have no experience with Browserify, but I think you should use something like debowerify to load this through bower instead of npm. @rafaelfranca @JangoSteve any thoughts? |
|
Why would you push to bower but not npm? If anything, I would push to just npm: people are starting to realise that a package manager that relies on another package manager which does the job just fine is pointless, and bower is starting to lose popularity. I can't think of a single dependency management project which doesn't work with npm. I can think of many (e.g. browserify) that don't work with bower. |
|
I really think we should not publish a frontend project in npm. This project is not a nodejs module. If Browserify choose to use npm to install frontend dependencies it not our problem. |
|
As kindly demonstrated by the biggest contributor of this project, npm isn't just for Node modules: https://github.com/JangoSteve/jQuery-EasyTabs/blob/master/package.json jQuery certainly isn't a Node module, but it is on npm: https://github.com/jquery/jquery/blob/master/package.json Of the top 15 trending JavaScript repos right now, only 3 of them aren't on npm. Hell, one of them is a UI library for AngularJS. I don't think that's a Node module. npm isn't just for Node modules. |
|
It's like you're saying, "we don't want people to use our project because we'd have to make it easy for them to install" |
|
I'm really sorry but I don't think we should add a new file every time a new frontend dependency project is created. Adding support for bower was easy and don't require us to deal with any external dependency registry like npm. It is not just we don't want to easy to install. We don't want to deal with npm. This is a Rails related project. |
|
I certainly understand that it's not a priority, but to completely reject it on some vague principle (which sounds a lot like "npm is hard")? |
|
The main reason is, it is not require to use this project. It is to be used in a Rails application. Rails applications uses sprockets, this project is included inside jquery-rails gem. I'm happy to support alternative workflow, but this workflow should not require any more work from us. This npm workflow require we release this project on npm, this is extra work for us and we don't want to have more extra work to support a non-official workflow. |
|
All it requires is that you type "npm publish" whenever you have a release. |
|
Yes, and this is extra work. Right now we don't need to type anything. 😉 |
|
Just to be clear is not just Again I'm not against support alternative workflows but it should be worth for us to maintain them. |
|
Using npm may be an alternative workflow in Rails but elsewhere it's become the standard. To front-end developers the Rails workflow is non-standard so it would be good to accommodate both. |
|
What is standard in the front-end community is hard to tell. We will stick with this for now. Thank you all for the inputs. |
|
Check out the Book of Modern frontend tooling. It's crowdsourced, so the stuff in there is all pretty widely used. There's a chapter on npm and browserify. |
|
I would just like to chime in to say I really don't like this sort of bone-headed approach about publishing packages, and it really doesn't help anyone. Most people use sprockets, sure, but there will eventually be someone (in this case, me and the other people who posted here) using projects like browserify-rails instead, which require installing packages through npm. Not having a package like this available means I will have to be the one jumping through fire hoops just in order to get a dependency that my entire project has been built based on to work now that I'm migrating it to browserify. Now, it would be unfair to expect any new node-unrelated project (such as this one) to publish to npm on the off-chance that someone might need it some time in the future, but I do believe (and very strongly so) that this should be done if there is demand, and in this case there clearly is. Saying "It takes me 5 minutes longer every time I need to release" is an extremely weak argument, since I don't see why you would be putting the effort into maintaining the project at all if you can't afford to spend 5 minutes to save a dozen of people 3 hours of work and a great effort just to figure out how to include this dependency in a reliable way. Apologies for the heated comment, but I found this extremely annoying, especially coming from the maintainers of such an ubiquitous project as jquery-ujs. I made this comment here, but I feel it can also be directed towards the ecosystem as a whole, which keeps going in directions that are against the ease of use that they're actually trying to promote. |
I have no words to express how unfortunate this comment is. It is 5 minutes of our time, of our lives. Sorry but you don't get to choose how we spend our time or how affordable 5 minutes of our day is, even more when we are talking about our free time. Even if we go into the merits of the argument above, it is quite flawed:
Why doesn't someone who deeply cares about this steps up to publish the package? As far as I know, you don't need to own the package source in order to push it. The license allows you to do whatever you want, as long as you keep the proper copyright and attributions. |
|
I did, but it's out of date because I don't know when it's updated. https://www.npmjs.org/package/jquery-ujs I will time how long it takes me to update it :) |
|
Idk how long it took to update, my terminal only tells me how long stuff took if it takes more than five seconds. And it didn't. C'mon guys, really? I'm completely happy to do it, but it will fall out of date. |
|
@callumacrae In my opinion you are free to keep it up to date as time goes. :) If you are afraid of it is getting out of date, one suggestion is to create a webhook and we can add it as payload. Then you just fetch it and push it to npm whenever there is a release. Then it won't require 5 units of time per release from anybody. |
|
And thanks for stepping up! :) |
|
@josevalim I'm sorry, I wrote that comment in a way that made me come off as a bit of a douche, apologies for that. What I really meant, although I worded it completely wrong, is that I think when maintenance cost is calculated for a package so ubiquitous, those are factors that should come into consideration. I'm definitely not going to disrespect you by telling you what to do with your time, and I definitely think it is better spent on work that affects a bigger amount of people, but I think this sort of issue should be seen from the same perspective as the one where you would be fixing a flaw that makes it impossible to use the package for an amount of users (i.e. a bug or a design problem): the same way time would be allocated for that, and it would eventually be fixed, I think it should be for this sort of thing. The package comes with every default rails project and quite a few projects become dependant, and that's why I think this sort of thing should be accounted for. The point is not relevant anymore thanks to @callumacrae, but I just wanted to clear up my stance and apologise for my comment above. |
|
@gabrielecirulli ❤️ 💚 💙 💛 💜 |
|
tl;dr: "it's convenient" and "works for me" is not a solid argument. Sure it's convenient to "just throw a There are plenty of JavaScript module systems out there (hopefully ES6 adoption will solve this once for all) so the fact that node uses CommonJS as a standard for its own ecosystem it doesn't mean that it should be a standard for all things JavaScript™. One last thing, "Bower is losing popularity" is not a strong argument either. It's the closest we have to a decent package manager which has the browser context in mind. If it's losing popularity we need to discuss better ways of doing things until we agree on something that makes everybody happy (instead of throwing rocks and "just use NPM"). This is how science works, actually. This blog post on the official npm blog has some interesting points on solving client side dependency hell. Yes, sadly we still struggle with it because people are biased, can't agree on standards and also looks like learning from other people's mistakes is completely out of question. |
|
@josevalim @rafaelfranca This is really useful for us here: shakacode/react-webpack-rails-tutorial#88 My new company will take over this. Let's figure out how we can work together. Going forward, there's no comparison with using Webpack and NPM for JavaScript. Please see this article I wrote on the topic: http://www.railsonmaui.com/blog/2014/10/03/integrating-webpack-and-the-es6-transpiler-into-an-existing-rails-project/ BTW, I met your team at RailsConf 2014. I didn't make 2015, as I've been insanely slammed setting up my new company ShakaCode based around combining Rails + React with Webpack. |
|
FWIW, I just wrote up some options on integrating jQuery and jquery-ujs with Rails + Webpack: http://forum.railsonmaui.com/t/considerations-for-jquery-with-rails-and-webpack/344 |
|
My reasons to not publish a npm package are still the same. I'm also aligned with what zepto.js maintainers think.
Sure! I don't have any problem to someone on the community register and maintain a npm package but I don't think we are going to make that official or part of our release process. |
|
@rafaelfranca I'll handle the publishing. I'll also check that the package.json works and provide good instructions. Would it be better to merge in a small number of changes so I don't have merge every time before publishing? Right now, I see only a small change to the readme to mention the alternative way of using this, and the addition of the package.json file, both of which should not affect you or other users. |
|
Doing both changes (README mention and adding package.json) means that the support it is official what is exactly what I want to avoid. Is not possible to publish a package on npm without having to change the repository? |
|
I can publish from a fork. I'm just wondering if that's going to be more confusing to the public. Possibly you can add me and another team members as backups that can support this? For what it's worth, Webpack is increasingly popular and advocates using only npm (for client or server js). We really enjoy using npm to manage JavaScript dependencies. It's as if we used to put rails gems in our our git repos and now we have Gemfile and Gemfile.lock (package.json and npm-shrinkwrap.json). I also have had zero other JS projects requiring bower. |
|
I really don't want to make official (and require the Rails team to do extra work) to something that is not advocate for Rails applications. We don't use and we don't recommend to use Webpack. Our assets pipeline uses Sprockets and it is the recommended way. We want to make possible to others chose their tools, but we also reserve our choice to not have extra work for things that we don't want to recommend. Adding official support to this repository means that if something goes wrong with the npm setup we will have to fix, and that is not something that we want to do. Of course there are people wanting to maintain this but who guarantees that they will stick around? If they left who will have to maintain this? For me, this is the same as requiring us to maintain rspec-rails even if the Rails default stack is using minitest. |
|
@rafaelfranca how about something to the effect of a pointer in the readme if one wants to use NPM? We could do that next to the info on bower? |
|
@callumacrae @justin808 Thanks folks. Now I have CSRF protection with my latest Webpack + Rails project. :) |
|
@nozpheratu Are you using React on Rails? |
|
@justin808 I'm using Rails + Backbone + Marionette. |
Please push this project to npm! :-)