Open justin808 opened 8 years ago
@dhh would you be willing to consider a PR on this one?
We got over 23,000 downloads in the past month on npm of jquery-ujs: https://www.npmjs.com/package/jquery-ujs
Installing JavaScript, given those numbers, via NPM is definitely something the community is doing.
I just reserved turbolinks on npm and would like to help either by doing what we're doing with jquery-ujs (supporting the distribution via a fork) or handing over turbolinks on npm to the rails team (along with jquery-ujs, if that's feasible).
Incidentally, the performance of our React on Rails demo at http://www.reactrails.com/ is quite snappy thanks to Turbolinks!
By the way, this doesn't change the fact that a gem still needs to be installed. One downside of including TurboLinks via NPM is that the version of the ruby code and the JS could could be different.
For React on Rails, v2+, we also have the JavaScript side distributed via NPM, and the Ruby code checks that the version numbers match.
The current code behind the http://www.reactrails.com includes Turbolinks in a "application.js" type file, as shown HERE.
So it is feasible to have a couple exceptions to including all dependencies via npm.
The bottom line is that if we think providing the JS code of TurboLinks via the Gem is the really the only desired distribution mechanism, I probably won't spend much time evaluating the option of npm. But if we might provide this, then I'll prototype this using a fork.
Thanks for your consideration.
Yeah, I think having Turbolinks on NPM makes lots of sense. @sstephenson is handling the release. Can you transfer the name to him? Thanks!
On Tue, Feb 2, 2016 at 7:50 PM, Justin Gordon notifications@github.com wrote:
By the way, this doesn't change the fact that a gem still needs to be installed. One downside of including TurboLinks via NPM is that the version of the ruby code and the JS could could be different.
For React on Rails, v2+, we also have the JavaScript side distributed via NPM, and the Ruby code checks that the version numbers match.
The current code behind the http://www.reactrails.com includes Turbolinks in a "application.js" type file, as shown HERE https://github.com/shakacode/react-webpack-rails-tutorial/blob/master/app%2Fassets%2Fjavascripts%2Fapplication_non_webpack.js#L5 .
So it is feasible to have a couple exceptions to including all dependencies via npm.
The bottom line is that if we think providing the JS code of TurboLinks via the Gem is the really the only desired distribution mechanism, I probably won't spend much time evaluating the option of npm. But if we might provide this, then I'll prototype this using a fork.
Thanks for your consideration.
— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/658#issuecomment-178754219.
Roger that @dhh! Let me know if we can also transfer jquery-ujs.
@callumacrae, my collaborator on jquery-ujs, pointed me to this:
I'd be curious as to how people are using this through NPM. Is this for those who opt out of the asset pipeline and use grunt or whatever themselves?
On Wed, Feb 3, 2016 at 7:09 PM, Justin Gordon notifications@github.com wrote:
Roger that @dhh https://github.com/dhh! Let me know if we can also transfer jquery-ujs.
@callumacrae https://github.com/callumacrae, my collaborator on jquery-ujs, pointed me to this:
[image: 2016-02-03_10-03-53] https://cloud.githubusercontent.com/assets/1118459/12791866/e58dbc8e-ca5d-11e5-89c8-6f4d164f2530.png
— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/658#issuecomment-179382993.
Basically, yeah. Front-end developers don't usually like interacting with the asset pipeline, and I've spoken to quite a few companies who have switched to using gulp or grunt for that reason (it's nice to be able to write tooling in your main language, you know?). react_on_rails, @justin808's project, uses webpack, which again gets its dependencies from npm.
Sounds good to me. Would be happy to see them mirrored, if we can find a workflow that's predictable and not likely to splinter the versions and dependencies.
On Thu, Feb 4, 2016 at 11:32 AM, Callum Macrae notifications@github.com wrote:
Basically, yeah. Front-end developers don't usually like interacting with the asset pipeline, and I've spoken to quite a few companies who have switched to using gulp or grunt for that reason (it's nice to be able to write tooling in your main language, you know?). react_on_rails, @justin808 https://github.com/justin808's project, uses webpack, which again gets its dependencies from npm.
— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/658#issuecomment-179760712.
To make a release, it's basically just a case of updating the version number in package.json (and if you use the npm version
command, it handles the git tag for you too), and then running npm publish
. It's super simple :)
Oh, I don't doubt the steps. Just that it needs to be part of the release pipeline.
On Thu, Feb 4, 2016 at 11:44 AM, Callum Macrae notifications@github.com wrote:
To make a release, it's basically just a case of updating the version number in package.json (and if you use the npm version command, it handles the git tag for you too), and then running npm publish. It's super simple :)
— Reply to this email directly or view it on GitHub https://github.com/rails/turbolinks/issues/658#issuecomment-179764634.
https://www.npmjs.com/package/turbolinks LIVE! We did it today. you can see it in use at http://www.reactrails.com.
PR showing using it from NPM: https://github.com/shakacode/react-webpack-rails-tutorial/pull/259
Can we please make the JavaScript part of turbolinks also available on npm?
I did the port for jquery-ujs and it's very popular.
So why does this matter?
I've setup https://github.com/shakacode/react_on_rails/ to make it super easy to use webpack with npm for client side assets. It's very awkward to have some assets load from standard Rails and the rest from npm. This will also helper users of other package systems.
In the long term rubygems should be used mostly for just ruby and JS assets should go on npm.
Thanks for considering this. I can create a fork and PR if you approve of this.