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.

[benmccann]

Sorry this has sat for awhile. On second look, I'm wondering if this is something users would always want. E.g. ?url might be helpful if you wanted to link to a transformed image or ?raw might be helpful if you wanted to embed a transformed image (or I guess you'd use ?inline for that - though I'm not quite clear on the differences between the two). It's hard to know what the most common use cases for these are and whether users would prefer to receive the transformed or originals by default. With this PR, it's no longer configurable and users are stuck with a single behavior. That doesn't feel great to me. Whatever the default, it seems like it'd be nice if users can alter it for their usecase

(btw, it looks like exlude takes precedence over include, which is a question I had while looking at this: https://github.com/rollup/plugins/blob/master/packages/pluginutils/src/createFilter.ts)