Example for component package.

[ckruppe]

Is it even possible to publish packages with components that use next-yak? As its not compatible outside nextjs i am not sure how an rollup config would look like to bundle an external package with prebuild components. Could someone shed a bit of light on that?

[jantimon]

Yes - it will be possible to publish packages with components that use next-yak - however that part is still wip and it requires a specific build setup since next-yak was initially designed for Next.js projects

We're currently exploring a Vite plugin version of next-yak that would enable exactly your use case.
It would allow to compile ui components during the build process to produce two artifacts: JavaScript and compiled CSS files.

Here's how it would work:

1. Your component library uses next-yak for styling

2. During build time, the Vite plugin:

   • Extracts all CSS from your yak styled components
   • Compiles dynamic prop-based styling into efficient runtime code
   • Generates stable class names and CSS variables

3. The build outputs:

   • JS files with the component logic
   • CSS files with all the extracted styling

Consumers of your package would simply:

import { MyComponent } from 'your-package'; // JS import
import 'your-package/dist/styles.css';      // CSS import

When they set props on your components, the runtime code efficiently toggles classes and sets CSS variables - all the heavy lifting is done at build time

Would that help you?

[ckruppe]

@jantimon thank you for your answer. :) yes that sounds good so far. :) Althought it would be nicer to not have to import the css extra but get it imported with your components. Like Linaria makes that possible right now. Comming from styled-components it was always nice to have import and forget all in one components. :) If this would not be possible thats fine. But it would make for an much better DX i think personally. :)
Would it then be possible to extract css only for seperate components? As i think thats an crucial feature to not have an css that bloats the codebase if you only use one component of an package with like 300 different ones. :)

[jantimon]

The main difference to styled-components is that we statically extract the CSS during compilation.
So we split the runtime code into JavaScript and CSS - whereas styled-components has only JavaScript code

The user of your published library would therefore need to add not only the JavaScript but also the CSS code so that their bundler picks it up correctly.

I still believe we could achieve this DX and compile the package into a format where the dist folder has for example a button.js which has an import to its button.css. This way a user of the library would only have to import the button.js or a barrel file.

However it's hard to know exactly how this would work before we get the Vite plugin up and running.

How would the ideal dist folder for that 300 component ui-library look like for you?
Can you give an rough example?

[ckruppe]

I still believe we could achieve this DX and compile the package into a format where the dist folder has for example a button.js which has an import to its button.css. This way a user of the library would only have to import the button.js or a barrel file.

Thats how Linaria does it too, i think.

Do you guys have plans for Rollup support too? (Asking only as we have the Rollup configs down for real full threeshaking support and so on, for our Libraries).

How would the ideal dist folder for that 300 component ui-library look like for you?

Thats an real tricky question. :D (300 was also an exaggerated example, i would say in our case its at most 50 or 60 debending on the Customers CI). In our libs it really depends on what we try to achieve. Right now our builds for Libraries consist of 2 different outcomes. Which are not easily possible with css in them later. At least for cjs bundles.

Right now our libs have roughtly this structure:

dist
  ╠ esm
  ║  ╠ same structure thats in source with all files transpiled
  ║  ╚ index.js (Exports all needed modules as named exports)
  ╚ index.js (The cjs bundle having all code bundled)

Sometimes we have sub strucktures in it for usecases in which we want to define different sub exports in package.json with the exports field.

Here would be an more concrete example of one of our public packages:
https://www.npmjs.com/package/@nfq/react-grid