Added package.json #380

Closed
wants to merge 2 commits into
from

Projects

None yet

10 participants

@callumacrae

Please push this project to npm! :-)

@lucasmazza
Member

@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?

@callumacrae

Browserify uses npm

EDIT: To clarify, I can run npm install jquery-ujs and then use require('jquery-ujs') instead of a path

@lucasmazza
Member

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?

@callumacrae

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.

@rafaelfranca
Member

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.

@callumacrae

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.

@japherwocky

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"

@rafaelfranca
Member

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.

@japherwocky

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")?

@rafaelfranca
Member

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.

@callumacrae

All it requires is that you type "npm publish" whenever you have a release.

@rafaelfranca
Member

Yes, and this is extra work. Right now we don't need to type anything. 😉

@rafaelfranca
Member

Just to be clear is not just npm publish. How we would know if this setup is working if we don't use it? If something is broken with it who will have to fix?

Again I'm not against support alternative workflows but it should be worth for us to maintain them.

@djgrant
djgrant commented Jul 10, 2014

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.

@rafaelfranca
Member

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.

@callumacrae

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.

@gabrielecirulli

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.

@josevalim
Member

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.

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:

  1. He has pointed out that supporting installation through other means can add other issues, leading to more maintenance.
  2. If we put 5 more minutes here, we would likely be taking 5 minutes from elsewhere. Maybe fixing a Rails issue in those 5 minutes is a much better contribution to the community that could save more than 3 hours for many more developers?

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.

@callumacrae

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 :)

@callumacrae

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.

@josevalim
Member

@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.

@josevalim
Member

And thanks for stepping up! :)

@gabrielecirulli

@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.

@josevalim
Member

@gabrielecirulli ❤️ 💚 💙 💛 💜

@rafaelrinaldi

tl;dr: "it's convenient" and "works for me" is not a solid argument.

Sure it's convenient to "just throw a package.json file there" and "let Browserify do its magic" but this is not how things work. Please, don't even start talking about standards, you don't want to go there specially when the context is client side tooling. There's a very thin line between convenience and making prudent decisions.
What about creating a Ruby gem, throwing a gemspec and jquery.js there because its convenient to install things through Ruby gems? That's just doesn't make sense. The context is different.

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.

@justin808
Contributor

@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.

@justin808
Contributor

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

@rafaelfranca
Member

My reasons to not publish a npm package are still the same. I'm also aligned with what zepto.js maintainers think.

Let's figure out how we can work together.

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.

@justin808
Contributor

@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.

@rafaelfranca
Member

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?

@justin808
Contributor

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.

@rafaelfranca
Member

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.

@justin808
Contributor

@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?

@rafaelfranca rafaelfranca referenced this pull request Oct 6, 2015
Closed

add package.json #443

@nozpheratu

@callumacrae @justin808 Thanks folks. Now I have CSRF protection with my latest Webpack + Rails project. :)

@justin808
Contributor

@nozpheratu Are you using React on Rails?

@nozpheratu

@justin808 I'm using Rails + Backbone + Marionette.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment