Feature Request - Add commandline option to generate compiled .scpt file from source

[damoclark]

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.

[johnelm]

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 osascript to osacompile. Then I tested it like this (assuming node is installed):

./index.js example.js

It produces the resulting compiled script as a.scpt (it uses this for the filename if you don't provide one).

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 command:

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 $.exit() from ObjC.import("stdlib");, which is needed by node-jxa to correctly set the exit code when errors occur.

Even if we were willing to forego the $.exit() call, using the library from another script fails with this cryptic error (I tested by requiring lodash):

Untitled.scpt:37:65: execution error: Error on line 3: Error: No error. (0)

OTOH, creating libraries in JavaScript and using them by requireing them as described in the README, is working great for me.

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:

• to be able to do scripting work in JavaScript, using more robust and familiar tools (than Script Editor) and workflows (vs. compiling to .scpt)
• use many of the libraries available in npm
• use your own .js files as libraries by simply requireing them
• being able to run executable (chmod +x) scripts without osascript

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

[damoclark]

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

The resulting script can be executed, using the osascript command:

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

But it can't be used as a Script Library.

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