use execjs to support more rubies

[rkh]

No description provided.

[josh]

Related: https://github.com/josh/ruby-less-js/blob/master/lib/less_js.rb

[josh]

The issue here is that less's @import directive requires FS access. It might be possible to have a simple ruby parser that preprocessors these directives and stitches together the full file and pass that to less.js.

[timfel]

therubyrhino (for jruby) should be api compatible to therubyracer, and is the much safer choice on jruby.

[cowboyd]

The long term solution is to have a way to use commonjs libraries and run commonjs applications from Ruby in a cross-platform way... basically an execjs for runtimes that can support embedding Ruby (of which there are now several).

That said, I'm amenable to a ruby pre-processor as an interim solution (provided an implementor can be found).

[gabetax]

I'd love this because therubyracer crashes on my production server due to some pax issues with the v8 library they're using.

rubyjs/therubyracer#118

[cowboyd]

As @josh mentioned, less.js needs file system access as well some Ruby glue to make sprockets dependencies work with @import statements. Also, to get the rails 3.1 helpers like image-url() to work, you need to inject Ruby code into the less tree.

For anybody landing here, I have pushed a working implementation of CommonJS modules. It is Ruby Racer only at the moment, but v8 part of it is kept at an arms length. It should provide a path forward to anybody wanting to implement a Ruby Rhino runtime and a native fs module.

With those to things, it should be a snap to port less.rb to commonjs. I'll get to it eventually, but bandwidth is limited.

[metaskills]

Interesting ticket. I just finished the sprockets preprocessor for the less-rails gem so that it makes all .less imported files a sprockets dependency. https://github.com/metaskills/less-rails

As @cowboyd said, the less-rails gem is injecting a small amount of ruby into less to get the asset helpers working. I have never looked deep into execjs yet, but would it have an interface to extend the JS context with Ruby cross each JS implementation?

[kares]

hey everybody, thought I've post here for a preliminary review - I've managed to get less.rb working with gem 'therubyrhino' (on JRuby) as well ... I've tried hacking with ExecJS first but it was insufficient to do the job (as @cowboyd already mentioned, due to required ruby gluing and import statements).

here's the code (don't worry about individual commits they will get squashed eventually) https://github.com/kares/less.rb

besides the changes in less.rb itself I did manage to almost completely monkey-patch therubyrhino to get it all working, thus I'll try to issue a pull request there first (hopefully @cowboyd will get happy about my rhino refactorings :)). now as I've built on the previous version, without the CommonsJS dependency, I might need to update that one as well ... especially since I needed to update the require logic.

if anybody is willing to try it out and/or give feedback, I'll appreciate it !

[rkh]

This still means embedding a JS runtime, which I'm kinda trying to get away from. Maybe execjs should be extended to support file operations. I mean, it's supported on node.js...

[kares]

@rkh right, although I'm not sure if it's entirely possible (not just due to file operations but having "native" JS objects acting like Ruby ones) with all backends ExecJS supports ... anyways I mostly cared of getting Less to work on JRuby and doing so with ExecJS seemed impossible with it's current API. but someone should definitely look at extending it :)

[rkh]

It means that you have to run V8 in a Ruby process for the entire life-span of the process, which affects all Rails projects and most Sinatra projects using less. It also means we cannot test the Sinatra Less support against Less 2.0 on Travis.

[cowboyd]

Though it started that way, It isn't just the file access anyore. In fact, thanks to @metaskills, the latest version of less-rails uses a preprocessor to extract all of the @import statements and handle them as sprockets requires. I reckon porting this over to the less gem proper would be relatively straightforward.

The real problem as it turns out is Sprockets asset helpers. In order to make asset functions like asset-path(), image-path() and friends work properly inside less stylesheets, you need the evaluator to call back into Sprockets. Doing this from a shelled out Node process would be tricky to say the least

@rkh I'm curious why you can't you test the Sinatra less support on Travis? I test less itself there. http://travis-ci.org/#!/cowboyd/less.rb

@kares I welcome your changes to therubyrhino. Getting it on par with therubyracer is something I've been wanting to do for a long time, and like everybody, I need all the help I can get :) I'm also excited to see Less working on JRuby. Hopefully you'll find that the CommonJS makes your life a lot easier since it implements all the require logic for you.

[rkh]

@cowboyd: Sorry, that now works, but it used to result in an exception. Recommendation from the Travis team was not to use libv8/therubyracer.

[tal]

Honestly I just want it so that i can have it use node. Therubyracer segfaults for me constantly.

[cowboyd]

@Talby Please read the discussion above as to why execjs cannot be used as a drop-in replacement. If you can open an issue on therubyracer, perhaps we can help you diagnose and fix your problems.

[fritzsche]

I'm not that much into the technical details but stubled about Cofee-Script-Pure https://github.com/charliesome/coffee-script-pure that was featured in "Ruby Weekly" newsletter.
Any chance that the used pure ruby TwoStroke https://github.com/charliesome/twostroke is good enough to execute less.js?

Would be nice to have a solution working without external JavaScriptVM. Working usually with MacOS, but now struggeling to port to windows environment :-( as V8 is not installing (there is an open ticked already).

[stereobooster]

duplicate #2

[mojavelinux]

Adding less to our project (awestruct) ended up being a nightmare with users because all of a sudden, everyone was in a world of hurt trying to get a JavaScript runtime installed that would make less happy. It was a platform nightmare.

I realize there are some technical challenges, but abstractions layers like execjs have proved to be very useful in improving the end user experience. Tilt is a good example (now at over 12 million downloads).

I strongly believe that the less gem should delegate the work of sorting out which JavaScript engine to use to another library, such as execjs. This would also make it easier to use with other gems that rely on JavaScript. Plus, new engines would be available as soon as they come online, like DynJS.

[cowboyd]

@mojavelinux I'm sorry that you've had such a rough time of it, and I know that the situation is not ideal. However, as detailed in this as in many other tickets, ExecJs does not provide visibility back into the Rails runtime needed for full integration with the asset pipeline.

The ultimate solution I think is, as you alluded, a single gem for running a tightly integrated JavaScript on all platforms. ExecJs in its current form however, is not that gem. I have toyed with other solutions, but have not had the development cycles to put out anything production worthy.

Finally, please note, that if you would like to use less without asset helpers, you can always use the https://github.com/maccman/less-rb gem which does, in fact, use ExecJs.

[lucaspiller]

👍

Heroku now advise against using therubyracer due to memory constraints:

https://devcenter.heroku.com/articles/rails-asset-pipeline#therubyracer

[cowboyd]

@lucaspiller That devcenter article is about 3 years out of date. I use therubyracer to compile assets on heroku all the time.

[ghost]

Would love to be able to run with the default JavascriptCore.framework i.e. jsc, that way apps could be submitted to the app store with LESS support. Any ideas for workarounds?

[kbrock]

Have tried to follow the treads. Excited to see the progress here removing the need for fs access. So calling back into sprockets is the current hurdle.

Is it possible to pass the necessary sprocket code into execjs? (e.g. write the asset helpers in javascript with a big hash and join function.)