Better support for "typescript import" of assets in .css.ts files

[kasper573]

The purpose of this thread is to discuss the possibilities of making the following code easier to achieve:

// foo.css.ts
import {style} from "@vanilla-extract/css";
import imageUrl from "./image.jpg";

export const foo = style({
  backgroundImage: `url(${imageUrl)`
});

This style of import is not supported out of the box by vanilla extracts integrations and is instead left to the consumer to solve on their own by configuring their bundler.

This topic started as a response to this issue and @askoufis asked me to turn this into it's own topic for discussion on github.

---

We can't ignore the fact that it's incredibly common to reference things like images and fonts in css files. Since the mental model of .css.ts files are supposed to basically be a typescript variant of css modules, I find it really strange to not have good support for idiomatic typescript imports, and instead basically promote runtime safety (url('/src/foo/bar.jpg')) instead of compile time safety when it comes to imports.

i.e. Vite does not yield any errors in development when urls are broken, and when building a production bundle it only emits a warning. Webpack will yield an error however. I haven't checked other integrations. But it's inconsistent at best, requiring the user to fill in the extra safety manually per bundler if one wants a failed build in the CI for broken assets, which may or may not be easy/possible to do.

I have two suggestions for improvements, one short term, one long term:

Improved documentation

Nowhere in the docs is there any mention of the limitations explored in this thread. I think it would be a helpful thing to highlight early on in the docs, i.e. referring the user to read the docs for their specific integration for further information on how to enable asset imports.

I think each integration should provide examples on how to implement asset support in .css.ts files, since each integration requires you to deal with this issue differently. ie. the webpack plugin will reuse existing loaders for assets (which I think is great!), but the esbuild and vite plugins will not, and instead require you to reconfigure the vanilla extract plugin with identical settings as your original esbuild/vite settings.

Improved integration extensibility

As mentioned in this thread, esbuildOptions does at least allow us to extend esbuild to support asset imports, but it does require some questionable workarounds to support both local project assets and assets from an npm package. For esbuild, I wish it could be solved more gracefully, i.e. by reusing the regular esbuild loader system. But to enable that we'd need to refactor @vanilla-extract/integration to accept the esbuild outdir option, and also update the compile step to properly treat multiple outputFiles from esbuild. I think this should be considered for the esbuild and vite integrations.

Overall however, I think the ideal goal would be to make each vanilla-extract integration configurable enough to support importing assets gracefully, preferably even adding asset import test cases for all integrations of vanilla-extract to make sure the library is stable with the ecosystem.

---

I'd love to contribute fixes! I'm familiar enough with esbuild to believe I could provide a PR to address some of these issues, and I could potentially find time to also look into the rest of the integrations, but I'd love to get a go ahead from a maintainer before I do so I know I'm building something that makes sense and we agree should be done.

[kasper573]

An idea I'm sitting with right now is that I could potentially refactor the esbuild and vite vanilla-extract plugins to not use a new esbuild process internally, but instead reuse the main esbuild process, and in that way we could reuse whatever asset import settings the user has (very much like the vanilla extract webpack plugin seems to do). But I'm not sure if this is a naive idea.

[JaceHensley]

I just ran into this today. Right now I have to configure the vanilla extract plugin like this

vanillaExtractPlugin({
  esbuildOptions: {
    loader: {
      '.png': 'dataurl',
      '.jpg': 'dataurl',
      '.jpeg': 'dataurl',
      '.svg': 'dataurl',
      '.gif': 'dataurl',
      '.webp': 'dataurl',
    },
  },
}),

---

I think one problem with re-using the existing esbuild process could be if you already have a plugin that transforms imports (svgrPlugin). I wonder how the webpack plugin handles that 🤔

[kasper573]

The new vite compiler solves this, so I'll close this! 🎉