This comment has been minimized.

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.

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.

This comment has been minimized.

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.

This comment has been minimized.

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

This comment has been minimized.

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.

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.

This comment has been minimized.

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.

This comment has been minimized.

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:

He has pointed out that supporting installation through other means can add other issues, leading to more maintenance.

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.

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:

He has pointed out that supporting installation through other means can add other issues, leading to more maintenance.

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.

This comment has been minimized.

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

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

This comment has been minimized.

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

This comment has been minimized.

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.

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 comment has been minimized.

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

This comment has been minimized.

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?

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?

This comment has been minimized.

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

This comment has been minimized.

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.

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.