Including Multiple JSX Scripts

[sberic]

I've encountered three methods:

1. //@include path/to/file-to-include.jsx
2. #include path/to/file-to-include.jsx
3. $.evalFile("path/to/file-to-include.jsx");

Some questions:

1. Is having multiple <ScriptPath> elements in the manifest file supported?
2. What is the recommended way to include multiple JSX scripts?
3. Where can I learn more about the ExtendScript environment - features beyond the standard ECMAScript implementation (e.g. this include stuff)?

[Bruce Bullis]

1. Not sure, but here's how extension manifests are built:  ExtensionManifest_v_5_0.xsd

What would calling out another script path in the manifest 'buy' you, that #including the script would not?

2. HTML5-based panels are the recommended way to trigger ExtendScript.

3. In the /SDK directory adjacent to ExtendScript Toolkit, you'll find "JavaScript Tools Guide CC.pdf".

[sberic]

1. Not sure, but here's how extension manifests are built: ExtensionManifest_v_5_0.xsd

Well, the only thing the XSD has to say about this is that the <ScriptPath> element can occur a minimum of zero times. As no maxOccurs is set, it would seem to follow that you could list as many as you like there and they would all get picked up. This doesn't work, though.

What would calling out another script path in the manifest 'buy' you, that #including the script would not?

Not much, really. Just another flexibility to configure your environment. Also, including a root folder also doesn't seem to work... You must select a single "root" JSX file that includes all the other files you require, apparently.

2. HTML5-based panels are the recommended way to trigger ExtendScript.

Hmm... the question wasn't about triggering ExtendScript, but about including ExtendScript files. What is the recommended way to do this? In lots of the Adobe-built panels, there seems to be a good deal of evalFile() going on. Is there a particular reason or benefit for that versus doing #include or //@include?

3. In the /SDK directory adjacent to ExtendScript Toolkit, you'll find "JavaScript Tools Guide CC.pdf".

Awesome. This is exactly what I was looking for.

Of relevance to this discussion is what the JavaScript Tools Guide CC.pdf file (p. 234) has to say about #include (emphasis mine):

Includes a JavaScript source file from another location. Inserts the contents of the named file into this file at the location of this statement.

...

Included source code is not shown in the debugger, so you cannot set breakpoints in it.

Is the last bit there the difference between the #include [and //@include] directives and the evalFile() approach? Will evalFile() retain the ability to debug?

In my own simple testing, debugging a script that's been //@include'd still works once. The panel needs to be reloaded for it to work. In fact, this appears to be the case with the "root" script included with <ScriptPath>, too! Is there a bug here potentially in that breakpoints only work once between panel refreshes?

Further, the //@include syntax does not appear in the PDF. Is this something new? Does //@ work in place of # in general?

[sberic]

Not sure how, but my previous response was marked as the Correct Answer (by me?). Definitely not the case. Would still like some input on this. Bruce Bullis​, any further light to shed on this?

[Bruce Bullis · Accepted solution]

What is the recommended way to do this?

There is no official recommendation.

In lots of the Adobe-built panels, there seems to be a good deal of evalFile() going on. Is there a particular reason or benefit for that versus doing #include or //@include?

None of which I am (or those whom I asked about it are) aware.

Is the last bit there the difference between the #include [and //@include] directives and the evalFile() approach?

It is _a_ difference...

Will evalFile() retain the ability to debug?

Yes; it's used in PProPanel, and I can debug PProPanel.

Is there a bug here potentially in that breakpoints only work once between panel refreshes?

Not sure it's a bug; refreshing the panel blows away all existing context.

Further, the //@include syntax does not appear in the PDF. Is this something new? Does //@ work in place of # in general?

Sorry, no idea. Note: That PDF hasn't been updated for a while.

Is there a particular reason or benefit for that versus doing #include or //@include?

I know of no specific benefit.

[sberic]

Is there a bug here potentially in that breakpoints only work once between panel refreshes?

Not sure it's a bug; refreshing the panel blows away all existing context.

To be more clear: I could only trigger a breakpoint in the JSX Context a single time before having to reload the panel (the CEP Context). Specifically, a breakpoint set on a script in ExtendScript Toolkit would only get triggered once until I refreshed the panel.

I put that last sentence there in italics because I just tried testing it again and can now reliably get breakpoints to trigger in JSX without reloading the panel. So... ¯\_(ツ)_/¯ on this one...

[RorohikoKris]

As far as I know, I think the main difference between evalFile and include is that include is handled when compiling to .jsxbin, whereas evalFile is handled at runtime.