`[[jsxgraph]]` and `[[javascript]]`, `input-ref-...` attributes block the use of JS module imports inside the block

[aharjula]

Not an issue for those that don't import stuff, but those needing to import stuff and act on inputs at the same time may suffer from this.

A problem exists in the current logic for the input-ref-... shorthand. It provides those references by wrapping the whole contents of the block in a function to be called only once those references have been resolved. One cannot use import statements as those need to be defined at the top-level, and that wrapping is most definitely not top-level.

For now, the workaround is to not use the input-ref-... shorthand if one needs to do imports; basically, don't do this, it won't work:

[[javascript input-ref-ans1="ans1ref" input-ref-ans2="ans2ref"]]
import * as magic from "somewhere out there";

...
[[/javascript]]

Instead, do the ref requests on your own like this:

[[javascript]]
import * as magic from "somewhere out there";

Promise.all([
 stack_js.request_access_to_input('ans1',true),
 stack_js.request_access_to_input('ans2',true)
]).then(([ans1ref, ans2ref]) => {
...
});
[[/javascript]]

We will need to figure out if we can lift imports out of the wrapping automatically from raw code, which would make things simpler for the author or if we need to do something else that would make things less compatible with normal JS scripting.

[aharjula]

There now exists a solution that lifts imports out of the code and places them outside the generated wrapper. But there are two edge cases that still cause trouble:

1. That logic does not respect comments. So one should not have commented out imports. In theory, we could strip the comments out before the lift, but that would remove the final bits of positional matching with the original code. Not that we have much of that anyway.
2. Content between the lifted out imports will be left behind; this should not be an issue, but in theory:

import AAA;                   import AAA;
BBB;                 ->       import CCC;
import CCC;                   BBB;
DDD;                          DDD;

In that case, should BBB affect in any way the result of import CCC, then the reordering might cause trouble. However, having an existing context affect an imported thing would be problematic anyway.

For now, unless anyone has any reason not to do so, I suggest that we proceed with this solution. The solution can be skipped by not using the input-ref-... feature; if it is not in play, then no lifting will be done, and the source keeps its original ordering.

[sangwinc]

Thanks @aharjula