Dang :/

Couldn't the CDN we use provide some API endpoint that'd prevent us from parsing any JS? Is there any effort ongoing on the topic?

I think you may be mixing this up with the other spot inJsDelivrEsmResolver where we parse the code from the CDN. Here's the issue about that -jsdelivr/jsdelivr#18538 - no public movement. But as they will ultimately give us a finite number of import synaxes, I believe that situation is solveable with regex.

Alternatively, shouldn't we switch to a regexp-less parser? (a small state machine that'd be able to split apart comments, strings and code)?

In this situation, we're dealing with userland code, which could look like anything. This was always going to be tricky to do perfectly without actually parsing the JS... my hope was to get it 99.5% correct (which I think we have). For that last 0.5%, I'm not sure. Can we make something to get to 99.999%? Or do we need to provide an "escape hatch" where the user can define special situations where over-matchingimport statements (e.g. because they are inside aconsole.log('import ...')) that should be ignored?

This could fix the regexp:

https://regex101.com/r/jtTZUA/1

(not handling multi-line enquoted string ... as that does not exist in JS)

Alternative: i opened#54014 (should fix this bug)

Closing in favor of#54014 then :)