[AssetMapper] Fix JavaScriptImportPathCompiler regression in regex

[PhilETaylor]

Q	A
Branch?	6.4
Bug fix?	yes
New feature?	no
Deprecations?	no
Issues	Fix #54078
License	MIT

Fixes regression in regex, fix provided by @nicolas-grekas in #54078

[carsonbot]

Hey!

Thanks for your PR. You are targeting branch "6.4" but it seems your PR description refers to branch "6.4,".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

[PhilETaylor]

I have also updated the https://regex101.com/r/1iBAIb/1 to https://regex101.com/r/1iBAIb/2 by adding the same change there.

[weaverryan]

Thanks for this :). Do we know if there is a test case that could be created to show the problem? Due to the complexity of this regex, we rely heavily on the tests to avoid regressions like this.

[PhilETaylor]

@weaverryan The reproducer I created was in the linked issue #54078

symfony new . --version="6.4.*" --webapp
php bin/console importmap:req @yaireo/tagify
php bin/console importmap:update 

[PhilETaylor]

If Im honest I dont really know what the root problem is enough to create some regression unit tests sorry. I just stumbled on and reported the issue first once I had a reproducer, and used @nicolas-grekas provided solution as a PR when requested.

[nicolas-grekas]

This happens because of big js files to parse with some content that trigger deep backtracking. Not easy to reliably test I fear...

[smnandre]

Thank you @PhilETaylor for this fix.
We're trying to handle so many cases with a single regexp...

Hopefully this one would bring us near the 99% we target, without having to implement a real JS parser (that would slow things down a lot for everyone)

[smnandre]

This happens because of big js files to parse with some content that trigger deep backtracking. Not easy to reliably test I fear...

I experienced the bug right now, while updating a branch i was working on the ux website... Fixed locally with a dirty patch...

            $relativeImportPath = $this->makeRelativeForJavaScript($relativeImportPath);

            return str_replace($importedModule, $relativeImportPath, $fullImportString);
-        }, $content, -1, $count, \PREG_OFFSET_CAPTURE);
+        }, $content, -1, $count, \PREG_OFFSET_CAPTURE) ?? $content;
    }

With your example i think i see the problem here ... https://regex101.com/r/WueQkU/1

.. and this file does not contains a single "import" 😭

So what about we also add a pre-check and ignore files that do not contain "import" ?

[stof]

@smnandre A str_contains check for import might indeed help for the case of files without any imports to exclude them faster. But I think we could still have such nasty backtracking for big JS files containing. So we need this PR.

Btw, I just thought about a case not covered by the current regex. But I'll wait for this PR to be merged before doing my PR as they would conflict.

[smnandre]

So we need this PR.

Of course! I just suggested an additional check :)

I'll open another one to throw an expression instead of returning null.

[nicolas-grekas]

Thank you @PhilETaylor.

[ph-il]

Got the same problem with
'@fullcalendar/core/internal.js' => [
'version' => '6.1.11',
],
So if you need more test case.