Error: SyntaxError: possible import expression rejected around line 1

[softmarshmallow]

This is not the right place for posting this issue. but since figma does not have a adequate place for these issues on github, i'm posting here.

I have perfectly working fine module which runs on a browser, but when i import and run on figma platform it won't run with following error.

Error: SyntaxError: possible import expression rejected around line 1

I'm sorry i cannot provide more context, but figma does not provide any readable context either. can you contact developers team and check if this is a known issue or provide more context so i can find where to start with my debugging?

Referencing Agoric/agoric-sdk#43 (comment)

[softmarshmallow]

Turns out import.ts file name is somehow breaking internal logic or package that figma is using to run plugin. can you guys share us what that is?
it took me 2 weeks to debug it.

• commenting lines line by line, see the effect.

[glebsexy]

Firstly, have you tried enabling Developer VM in order to see more detailed error messages? Without it the error can be completely different from what is actually happening in your code.

Secondly, there is a place for plugins API issues: https://forum.figma.com/c/plugin-api/20 — you can even choose whatever the appropriate subcategory is for your request and post there. If you think you found a bug in the API, you need to post the reproduction steps in the bugs category. If you need help from the community to figure out what could be wrong, feel free to post a question in the questions category.

(I don't work for Figma)

[warner]

Hey, saw your comment on agoric-sdk and thought I'd provide a little context. The SES shim (which we develop, and now lives in https://github.com/endojs/endo/tree/master/packages/ses) transforms a regular JS environment into a more-securable "SES" (Secure ECMAScript) environment when you call lockdown(). A big goal for SES is to make it safe to use eval(code, endowments): you can evaluate arbitrary attacker-supplied code, and the only interesting authorities it can get to are the ones you give it as endowments. The worst thing the code can do is to halt your program by running an infinite loop or exhausting memory, but other than that, it cannot exceed the authority you choose to give it. In particular, it cannot cause network activity unless that's one of the endowments you provide.

To maintain this, the SES shim needs to block any instances of the "dynamic import expression" in the code being evaluated. This is a relatively recent JS thing where modules can do const namespace = await import(url), and get back a Promise that resolves to the result of importing some arbitrary URL. This causes network IO, which is clearly beyond the limits of what SES will allow to confined code. The SES shim doesn't use a full parser, so we can't tell precisely when the evaluated code contains a real import, but we do employ a regular expression to spot anything that might be a real import expression: we get false positives but not false negatives. This regexp has gotten better over time, but there are still probably a few false positives left.

The "censor" is named rejectImportExpressions and lives at https://github.com/endojs/endo/blob/master/packages/ses/src/transforms.js#L131 . The comments there (and the regexp itself) may help you figure out what part of your code is triggering the check.

The error message you got looks like it came from an earlier version of SES. The newer version might be less picky. I imagine it's up to the Figma platform to upgrade.

One of the tricky and frustrating things about SES and eval is that it's pretty common for line numbers to get lost by the time an error message is generated. From your error message, it sounds like your code is being somehow bundled into a single line, so obviously line numbers aren't going to be very helpful.

Try searching through your source code (especially the output of any bundling step, if possible) for the word import, followed by an open parenthesis or by the beginning of a comment (either // or /*). Before we improved the regexp, I ran into this a lot with innocent comments like:

// This could be either an import
// or an export

because the regexp can't tell that we're already in a comment when it sees import, and it can't tell that the // which follows import isn't itself followed by the (url) that would complete the dynamic import expression:

const namespace = await
import
// intervening comment is ignored
(url)

hope that helps!
-Brian (contributor to SES / Endo)

[softmarshmallow]

@zyumbik

Nothing really usefull on developer vm console

Plus, can you confirm the use of endojs proposed by Above @warner's comment?

Thanks @warner . that clears lots of things :) (yet i cannot solve it by only my side)

Also can you propose other scenarios that something wen't wrong? I haven;t went through every single line, but i confirmed that there are no dynamic import usage and misconfigured import statement.

[softmarshmallow]

I scoped down to the packaage i'm trying to import causes this error.
https://github.com/bridgedxyz/CoLI/tree/main/packages/coli-builder

AFAIK https://github.com/bridgedxyz/CoLI/tree/main/packages/coli-builder/import this folder causes this error.
only removing whole directory solved the issue. and the code content seems inocent.

Can you confirm that naming the directory with token "import" also might cause this error? @warner

[warner]

I wouldn't expect a directory by that name to cause a problem, but source bundling steps might incorporate it into an identifier somehow, which could conceivably trip the regexp. Or if something is importing the import directory (i.e. assuming there's an index.js inside it), that might do it. Or maybe something is reaching for e.g. import/./file.js, but something else is collapsing the path in a weird way and turning it into import//file.js, which would look like a comment separator and trigger the regexp.

When I've had to track this sort of think down in the past (before we improved the regexp to be less eager), my process was something (painful) like:

• change the SES (now Endo) regexp-applying code: if it found a match, figure out the string offset of the match, slice it down to the 100-ish characters surrounding the match, console.log those, then throw the error as usual
  • or include the surrounding characters in the error object
• rebuild the SES shim with my modified regexp-applying code
• re-run the target program with the modified SES shim
• watch the console output and use the enhanced error to give me something to search the source tree for

Not fun, but it worked at least once. The culprit turned out to be a comment I'd written that ended in the word import, and the // comment marker on the following line is what qualified it as a match for the regexp. Ugh, that was a long night :).

[softmarshmallow]

Doing endless commenting out the whole lines, still having painful nights :(

Or just perhaps can you modify the package to print out the import statement as error message (bundled or not) so the error can be much helpful. and I think this is necessary since it's a runtime error (at least what feels like to me)

Think This talk should take a place in other thread.

It just feels almost impossible to debug this. (off topic - figma's developer environment is weight too poor)

P.s. can you share the regex value? so i can search the dist source and original source with that

[softmarshmallow]

@warner So i found where the error is caused.

https://github.com/bridgedxyz/CoLI/blob/9eb681fdd8c054645d4b570538d9731af8ebca05/packages/coli-builder/import/import.ts#L61

Removing the class member method import solved the issue

It's not caused by comment or any other thing but method named import caused this.

I think class is not cuasing the problem (I don't know since Import class starts with upper i -> I)

Does the ses package has the logic not the check the function named import?

Reference: gridaco/CoLI#11 (comment)

[softmarshmallow]

Closing this issue, creating new one on endojs
endojs/endo#773