-
Notifications
You must be signed in to change notification settings - Fork 4
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
Feature Request - Add commandline option to generate compiled .scpt file from source #31
Comments
Hi Damo, Sorry it's taken me so long to reply. I've done some playing with this. To try it, I changed the command in line 8 in node-jxa.js from ./index.js example.js It produces the resulting compiled script as I think it's reasonable to expect that the resulting .scpt file 'can then be used and shared as like any other applescript' (quoting from your request), but it actually can't. The resulting script can be executed, using the osascript a.scpt But it can't be used as a Script Library. If this is attempted, the resulting .scpt file crashes the osa process, and hard. If run from Script Editor, it (Script Editor) is killed too. It doesn't seem to like the use of the Even if we were willing to forego the
OTOH, creating libraries in JavaScript and using them by I know it seems inefficient to bundle dependencies into an in-memory script every time, but I've never encountered any performance pain from it. Have you (sincere question)? In any case the main intents and benefits (IMO) of this library are:
.. so to be honest I haven't been inclined to add the compile feature. But I tried it anyway to check it out, and it's not doable, at least not without a lot of work. Hoping you'll understand. Thanks much for the request! Cheers, |
hi @johnelm Thanks for such a considered response. I think I may not have expressed the intention of the request well. While I do highlight the overhead of browserify having to bundle the script before executing it on each invocation, my primary goal is in relation to distributing the scripts themselves. To bundle/share using the framework you have with node-jxa, you have to share a collection of source files essentially. What I was looking for was a way to compile or otherwise bundle up a distribution to a single file that can be shared, and shared in a way that existing applescripts currently do (i.e. a compiled .scpt file).
So this was exactly what I was after. A compiled file that can be executed using osascript, or by other automation services built into macOS (i.e. drop the file into a predefined folder for a given app).
The framework under which you have built node-jxa allows libraries to be reused via the standard npm package management tools and ecosystem, so I wasn't proposing to distribute libraries using node-jxa. This would seem redundant, and as you explain, requiring them works well already. It is also a well-known method of writing with javascript. This makes node-jxa a great tool to bring those skilled developers into the macOS automation ecosystem. The only gap with node-jxa is distribution of the scripts themselves. So all I was looking for was a way to distribute a complete built script much like people typically do now with compiled applescripts. You drop a single file into a predefined folder and the apple automation system picks it up and integrates it. I hope this makes more sense than my original request comment. :) So the results of your playing were exactly what I was asking for. :) Cheers, |
Hi John,
It seems that node-jxa uses browserify to generate a single script file each time it is invoked. For scripts that are called often, or that are substantial in size, this is quite a bit of overhead.
So I was wondering whether the node-jxa command could accept an option that changes its behaviour to instead generate a .scpt file using
osacompile
command. This .scpt file can then be used and shared as like any other applescript, but also isn't regenerated on each invocation.Perhaps a
-c
option which takes a file path for the resulting compiled .scpt file.I hope this makes sense?
Is this something you would consider adding to this great tool?
Many thanks.
Damo.
The text was updated successfully, but these errors were encountered: