fix(assetImportMetaUrl): allow ternary operator in template literal urls

[kajo404]

Description

The recent fix to query parameters in template literals (#13034) broke some imports in our project which use ternary operators in template literal strings. This change keeps the fix to query parameters while allowing ternary operators by finding the first '?' character that is not in between curly brackets.

This was valid before:

new URL(`./resources/image${this.isHighContrastModeActive ? '-white' : ''}.svg`, import.meta.url).href

But now breaks the build because a split is performed on the '?' in the ternary operator.

Additional context

We could simply move the ternary operator outside of the template literal, which fixes our issues. As the change in #13034 might affect others, this fix can prevent the need for code refactoring due to a regression.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[patak-dev]

I think this may be better than a regex here. I was thinking we could check for ${ but this may be enough.

[sapphi-red]

Because we are parsing the url by this.parse later, I wonder if we can get the index during that. But given that this is a regression, I think it's fine to merge this for now.

BTW how does this work when a variable exists after ? (e.g. new URL(`./foo?bar=${bar}`, import.meta.url))?

[patak-dev]

new URL(./foo?bar=${bar}, import.meta.url)

Good point. This one would detect the ? correctly, but later do a JSON.stringify of the globOptions so the query field we'll end up with a static bar=${bar}. This wasn't working before though, so as you said in the previous message at least we should merge the regression we introduced in 4.3. Fixing bar=${bar} should be possible if we render the object field by field and use a template string for the query.