New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added package.json #380

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
10 participants
@callumacrae

Please push this project to npm! :-)

@lucasmazza

This comment has been minimized.

Show comment
Hide comment
@lucasmazza

lucasmazza Jul 10, 2014

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?

Member

lucasmazza commented Jul 10, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@callumacrae

callumacrae Jul 10, 2014

Browserify uses npm

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

Browserify uses npm

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

@lucasmazza

This comment has been minimized.

Show comment
Hide comment
@lucasmazza

lucasmazza Jul 10, 2014

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?

Member

lucasmazza commented Jul 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@callumacrae

callumacrae Jul 10, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jul 10, 2014

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.

Member

rafaelfranca commented Jul 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@callumacrae

callumacrae Jul 10, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@japherwocky

japherwocky Jul 10, 2014

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"

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

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jul 10, 2014

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.

Member

rafaelfranca commented Jul 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@japherwocky

japherwocky Jul 10, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jul 10, 2014

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.

Member

rafaelfranca commented Jul 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@callumacrae

callumacrae Jul 10, 2014

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

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

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jul 10, 2014

Member

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

Member

rafaelfranca commented Jul 10, 2014

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

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jul 10, 2014

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.

Member

rafaelfranca commented Jul 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@djgrant

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

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

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jul 10, 2014

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.

Member

rafaelfranca commented Jul 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@callumacrae

callumacrae Jul 11, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@gabrielecirulli

gabrielecirulli Dec 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Dec 3, 2014

Contributor

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.

Contributor

josevalim commented Dec 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@callumacrae

callumacrae Dec 3, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@callumacrae

callumacrae Dec 3, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Dec 3, 2014

Contributor

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

Contributor

josevalim commented Dec 3, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Dec 3, 2014

Contributor

And thanks for stepping up! :)

Contributor

josevalim commented Dec 3, 2014

And thanks for stepping up! :)

@gabrielecirulli

This comment has been minimized.

Show comment
Hide comment
@gabrielecirulli

gabrielecirulli Dec 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Dec 5, 2014

Contributor

@gabrielecirulli ❤️ 💚 💙 💛 💜

Contributor

josevalim commented Dec 5, 2014

@gabrielecirulli ❤️ 💚 💙 💛 💜

@rafaelrinaldi

This comment has been minimized.

Show comment
Hide comment
@rafaelrinaldi

rafaelrinaldi Dec 18, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@justin808

justin808 Sep 11, 2015

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.

Contributor

justin808 commented Sep 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@justin808

justin808 Sep 11, 2015

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

Contributor

justin808 commented Sep 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Sep 11, 2015

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.

Member

rafaelfranca commented Sep 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@justin808

justin808 Sep 11, 2015

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.

Contributor

justin808 commented Sep 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Sep 11, 2015

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?

Member

rafaelfranca commented Sep 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@justin808

justin808 Sep 11, 2015

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.

Contributor

justin808 commented Sep 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Sep 11, 2015

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.

Member

rafaelfranca commented Sep 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@justin808

justin808 Sep 12, 2015

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?

Contributor

justin808 commented Sep 12, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@nozpheratu

nozpheratu Jan 29, 2016

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

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

@justin808

This comment has been minimized.

Show comment
Hide comment
@justin808

justin808 Jan 30, 2016

Contributor

@nozpheratu Are you using React on Rails?

Contributor

justin808 commented Jan 30, 2016

@nozpheratu Are you using React on Rails?

@nozpheratu

This comment has been minimized.

Show comment
Hide comment
@nozpheratu

nozpheratu Jan 30, 2016

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

@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