- Notifications
You must be signed in to change notification settings - Fork37
-
Is there some trick to building ruby2js? I've got a few largish ruby files that I'm trying to convert as part of a Vite build and it's taking an inordiate amount of resources to build. For example, sitting on 22GB memory at 100% CPU for 10 minutes! So I attempted to build the ruby2js.js file with mixed success. I upgraded to the latest opal and found there was a problem with the sourcemap code. I resolved that, but then ended up with a crash in the parser code with the sample 'puts "2A".to_i(16)' when testing the rollup package. This crash is in the parser gem and is still there when rolling back to the original opal version. What level of the parser gem was used in the build? I was hoping to be able to build a running package that I could put some debugging in tofind out where the time is going, but I can't seem to build anything that actually runs. Any help would be appreciated. |
BetaWas this translation helpful?Give feedback.
All reactions
Replies: 2 comments 1 reply
-
I tried a different approach by writing a quick and dirty Vite plugin to transform the code using the actual ruby2js gem directly. The difference is remarkable as the time to build dropped from about 10 minutes to around 20 seconds. I'm thinking that the Opal translation of the parser code is pretty inefficient and that converting all the code to JS first is a nice idea, but doesn't work very well. Of course, you need Ruby in your build environment, but that shouldn't be a big hurdle. Here's my sample Vite plugin construby2js=()=>({name:'ruby2js',transform(code,id){lettransformCode=code;letmap=null;if(id.endsWith('.rb')){letchild=spawnSync(`ruby2js --es2022 --autoexports true --underscored_private --identity --sourcemap --filter esm --filter functions --filter camelCase --filter active_functions${id}`,{shell:true});constresult=JSON.parse(child.stdout.toString());transformCode=result["code"];map=result["sourcemap"];}return{code:transformCode, map}}}) |
BetaWas this translation helpful?Give feedback.
All reactions
-
@esb I came to much the same conclusion as you: the native Ruby version is considerably faster, which is why I ended up changing the esbuild plugin back to spawning to run Ruby for the conversion. Based on other issues I've run into in the past, I'm tempted to say we keep the Opal version strictly for demo purposes (like on the website to try out) but otherwise deprecate it and have a note saying We need a total revamp of the Vite plugin (I'd written a while back looking for maintainer help)—if you feel your rewritten plugin's in pretty good shape, would you be willing to submit a PR to update ours to go with that approach? Then we'd have feature parity between esbuild & Vite which would rock. |
BetaWas this translation helpful?Give feedback.
All reactions
-
At the moment, as you can see, the options are all hard-coded and these would need to be generalized in order to make it fully useful as a plugin. It's certainly something I can have a look at doing. |
BetaWas this translation helpful?Give feedback.