Skip to content

[AssetMapper] Fix JavaScriptImportPathCompiler regex for non-latin characters #58659

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 9, 2024

Conversation

GregRbs92
Copy link
Contributor

@GregRbs92 GregRbs92 commented Oct 25, 2024

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

Update the regex in JavaScriptImportPathCompiler so that imported functions having non-latin characters still match the regex.

Example

import { ɵmyFunction } from './others.js'

The code above was not working prio to this fix, because of the ɵ

@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 7.2 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@carsonbot
Copy link

Hey!

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

Cheers!

Carsonbot

@@ -42,7 +42,7 @@ final class JavaScriptImportPathCompiler implements AssetCompilerInterface
(?: # Import statements (script captured)
import\s*
(?:
(?:\*\s*as\s+\w+|\s+[\w\s{},*]+)
(?:\*\s*as\s+\w+|\s+[\p{L}\w\s{},*]+)
Copy link
Member

@nicolas-grekas nicolas-grekas Nov 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know which encoding PCRE uses when the u modifier isn't set, but this doesn't work with e.g. character é.
I think the correct patch is to add the u modifier when the input is UTF-8 and contains non-ascii chars:
self::IMPORT_PATTERN.(preg_match('{[^\\x00-\\x7F]}u') ? 'u' : '')
then this change here should be reverted

@OskarStark OskarStark changed the title [AssetMapper] Fix JavaScriptImportPathCompiler regex for non-latin characters [AssetMapper] Fix JavaScriptImportPathCompiler regex for non-latin characters Nov 4, 2024
@@ -50,7 +50,7 @@ final class JavaScriptImportPathCompiler implements AssetCompilerInterface
)
\s*[\'"`](\.\/[^\'"`\n]++|(\.\.\/)*+[^\'"`\n]++)[\'"`]\s*[;\)]
?
/mx';
/mxu';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will break parsing non UTF8 files. My previous suggestion was made to handle such cases.
We can merge as is and wait for someone to fill in a bug, maybe UTF-8 is the only encoding found in practice?
🤷

@fabpot
Copy link
Member

fabpot commented Nov 9, 2024

Thank you @GregRbs92.

@fabpot fabpot merged commit d9cecb7 into symfony:6.4 Nov 9, 2024
10 checks passed
This was referenced Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants