fix: exclude assets with ?raw and ?url queries from processing

[didoin]

• Quick Checklist

• I have read the contributing guidelines
• I have written new tests, as applicable (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• I have added a changeset, if applicable

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  This fixes the bug discussed in The plugin processes images with ?raw and ?url queries when it shouldn't #748.

• What is the new behavior (if this is a feature change)?

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this
  PR?)
  No.

• Other information:

[changeset-bot]

⚠️ No Changeset found

Latest commit: b67d1c7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[benmccann]

I wonder if it should be something more like \?(.*&)?(url|raw) in case it is combined with another query parameter. Probably unlikely, but maybe safer?

[didoin]

The official Vite documentation explicitly talks about ?url suffix and ?raw suffix.
Static Asset Handling

Also, I think your pattern doesn't allow specifying future query parameters (perhaps for new transformers) that are prefixed with raw or url (?rawable example, I know it's a bad example 😂).

[JonasKruckenberg]

specifying future query parameters (perhaps for new transformers) that are prefixed with raw or url

For what its worth, I think we should not worry about that right now, if a situation arises in the future where there are more special query params like that we can easily push another version then.

[didoin]

If you feel that a more rigorous regular expression would be more appropriate, that's perfectly fine. From my perspective, though, it might not be necessary in this case, since "vite" expects these parameters as a suffix.

As for the "future query parameters" concern, I was also considering the possibility of custom parameters that users might define through the extendTransforms function. It seems like we could avoid potential issues down the line by addressing this now.