import expression false positives

we’re encountering a lot of issues with false positives in the detection of import() statements when evaluating code from npm

possible import expression rejected around line {number}

I’ll use my lavamoat-survey tool to get a list of offending code samples in popular packages on npm

[erights]

I am working on optional lightweight “evasive” transformations that would do something like this, still without parsing, at the price of possibly changing the meaning of programs it is applied to. Anything that parses could instead do an accurate job, and should, rather than using the evasive transformations I’m writing. PR coming soon.

[dtribble]

Is LavaMoat in position to do a more accurate analysis? I was wondering whether ew could add two more options for each module:

• this appears to have a dynamic import but doesn’t actually
• this actually does have a dynamic import

These options would suppress the conservative check at runtime, in the same way that permitting access to globals opens a hole that will need to managed.