You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've been using VE extensively to build our design system library at our company. One issue we encountered is that if you have any vanilla extract .css.js files, you require the bundler to take over and build them on dev time and production build time. This isn't a huge deal, but sometimes we have customers who are either unable to customize their bundling setups or have bundling setups that are too customized and would require too much effort to implement vanilla extract bundling.
The easy solution for this would be to just pre-compile the .css.ts files into .vanilla.js and .css files. This is facilitated by the new bundle option. However, by itself this feature is incomplete. We also have customers using vanilla extract in the front end - and they sometimes import classNames for extensions or overrides, which strip out the "full" className to the singular "identifier" className. If we pre-bundle our VE files, we'd lose the list of registered classNames in the compiler, which will break overrides and other types of selectors.
My suggestion for this would be to have an option to save into memory a .vanilla.registrations.js file, which has all the information that VE would otherwise generate if it had access to the original source. Implementation could be as simple as looking into disk to see that there are adjacent registration files to vanilla.m?js files. This way if someone isn't using VE, they get to use the generated CSS but if they are, they get to use the robust type safety for CSS overrides as well.
I'd be happy to implement a draft for this. I'm already familiar with the Vanilla Extract codebase and have contributed to it in the past.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey all,
We've been using VE extensively to build our design system library at our company. One issue we encountered is that if you have any vanilla extract
.css.js
files, you require the bundler to take over and build them on dev time and production build time. This isn't a huge deal, but sometimes we have customers who are either unable to customize their bundling setups or have bundling setups that are too customized and would require too much effort to implement vanilla extract bundling.The easy solution for this would be to just pre-compile the
.css.ts
files into.vanilla.js
and.css
files. This is facilitated by the newbundle
option. However, by itself this feature is incomplete. We also have customers using vanilla extract in the front end - and they sometimes import classNames for extensions or overrides, which strip out the "full" className to the singular "identifier" className. If we pre-bundle our VE files, we'd lose the list of registered classNames in the compiler, which will break overrides and other types of selectors.My suggestion for this would be to have an option to save into memory a
.vanilla.registrations.js
file, which has all the information that VE would otherwise generate if it had access to the original source. Implementation could be as simple as looking into disk to see that there are adjacent registration files tovanilla.m?js
files. This way if someone isn't using VE, they get to use the generated CSS but if they are, they get to use the robust type safety for CSS overrides as well.I'd be happy to implement a draft for this. I'm already familiar with the Vanilla Extract codebase and have contributed to it in the past.
Beta Was this translation helpful? Give feedback.
All reactions