add data url support

[romainmenke]

This change adds support for :

@import url(data:text/css;base64,...)

Before this change a data url would throw an error, so this is not something that is being used today by users of this plugin.

As far as I can tell the change required is minimal and everything just works.

• media queries
• at layer
• sourcemaps
• nesting multiple imports within data urls

---

I don't this is useful on its own.
Authors should not be base64 encoding CSS source code and storing this in @import urls.

It can however be useful for other plugins that have non-standard interactions with @import.

Another plugin that does want to provide extra features can choose to store as base64 instead of inlining.

This keeps the source valid with all @import rules before anything else and all in the correct order.

---

An alternative approach to this is that other plugins use the file system.
Instead of inlining they can store the contents in a file and update the @import rules so they each is fully standard CSS and everything points to a local file.

Both approaches have merit and I don't have a strong preference between them.

[RyanZim]

Implementation looks good

[RyanZim]

An alternative approach to this is that other plugins use the file system.
Instead of inlining they can store the contents in a file and update the @import rules so they each is fully standard CSS and everything points to a local file.

The problem with this approach is that you'd need to do an absolute path to a temporary file, which will create a dependency message for that file, causing runners to watch those files in watch mode, which is undesirable. I think the data URL approach should be preferred for that reason.

Not sure if anyone will use it, but it's not complicated to add, so no real reason not to.

[romainmenke]

The problem with this approach is that you'd need to do an absolute path to a temporary file, which will create a dependency message for that file, causing runners to watch those files in watch mode, which is undesirable. I think the data URL approach should be preferred for that reason.

Cool! Thank you reviewing this 🙇

[RyanZim]

Published in [email protected]

[romainmenke]

Thank you for the release @RyanZim 🙇