Generate styles without a bundler?

[michaelwarren1106]

I would love to experiment with this tool as the main way to get css into my LitElement web comps, but we don’t use and bundlers at all currently and I’d rather not introduce one just for a build step.

Is there an example of generating the css files without a bundler plugin? Say with just a regular node js script?

[markdalgleish]

We don't support this currently, but I've definitely thought about how we might support usage outside of bundlers. I'm curious to hear more about what you think this would look like from a consumer API perspective?

[michaelwarren1106]

Well, on the surface I’d think that the scoping of css vars and such is the main reason for using alongside a bundler because in order to generate something hashed and have the css still work, you’ve got to have some template somewhere that you can add the hash attrs to.

I’m not sure how that would be solved, but my personal use case is generating css for use/importing into es6 LitElement components where the name-spacing of css vars and classes is less important because of shadow dom. But if I get to set the name-space to something of my choosing, I could easily jus my add that attr manually in my templates if I’m sure it wouldn’t change. If it’s auto generated at random every build that’s harder with no bundler and dozens of template types/locations/structures across various frameworks.

In my narrow use case it would be cool to have some cli command that finds all the .css.ts files and essentially replaces them — with some config to control things like output directory and such — with some sort of importable file that instead of containing css-generating functions, just exports a string of css.

In my design system I currently have a completely custom setup for turning scss files (run through scss, then postcss,tailwind and purgecss) into a simple ts file that’s like:

export const css = '...the css';

then when ts compiles that gets turned into an es6 style import for runtime and my components are distro’d as es2017.

so if we had something to replace all that custom stuff that starts in TS instead of scss, it would make using design tokens in js/json way easier. If we could tailwind/purge also that would be the best of all the worlds.

I definitely don’t really want to use scss design tokens when js/json would be more extensible by far.

[cseas]

I'd like to see this implemented as well. I have a React UI component library which is using styled-components for styling. I'm trying to replace styled-components with Vanilla Extract but this is not possible right now because VE would require me to start using a bundler while currently my entire library ships with a simple tsc transpilation.

I'd like to avoid all the overhead that comes with trying to bundle a library in ESM format that consumer projects can tree shake. A bundler isn't really the right tool for this because most bundlers output flat files which I'd like to avoid.

tsc works perfectly since as a library author, I don't need to concern myself with bundling into flat files. Bundling is the job of the consumer project that's shipping the output to browsers. And needing a bundler for a styling solution is a huge friction for adopting VE for this use case.

Related:

• errors when using external ui library implemented with vanilla-extract in next.js app #940
• Vanilla Extract and Design Systems #620 (comment)