Shared style
; }; ``` ### Specificity [#specificity] The `classStyle` prop accepts arrays, ternaries, and conditional expressions. Merging follows one rule: **the right side wins**. If `isActive` is true, the properties of `active` override the properties of `base` — always. ```tsx title="Component.tsx" const styles = css.create({ base: { color: "gray", fontSize: 16, }, active: { color: "blue", }, }); classStyle={[styles.base, isActive && styles.active]} ``` Because the compiler controls the merge, the cascade specificity problem disappears entirely. Writing the merge as an operation, where $\oplus$ combines styles left to right, disjoint styles simply concatenate: $parse(A \oplus B \oplus C) \to \text{"classA classB classC"}$ And when two styles set the same property, the losing atom on the left is filtered out at compile time — it never reaches the output: $parse(A_{color} \oplus B_{color}) \to \text{"classB"}$ A shorthand against a longhand is the exception: the longhand wins wherever the two meet, in either order. See [Specificity](/docs/reference/specificity). ## Types all the way down [#types-all-the-way-down] Styling shouldn't require a runtime. Plumeria treats styles as **type schemas** rather than runtime objects — in fact, the package's only entry point is a `.d.ts` file. There is no JavaScript to import: ```json title="package.json" { "name": "@plumeria/core", "exports": { ".": { "types": "./lib/css.d.ts", }, }, } ``` Static styles resolve to class names entirely at compile time. The only dynamic pieces — function keys and variant props — compile down to CSS variables, so even they leave no JavaScript behind. Every API compiles to nothing but static class names and CSS: * No runtime bundle * No runtime evaluation * No runtime parsing * No runtime dependencies Of course, "zero-runtime" doesn't claim the cost vanishes — it claims the cost moves. All of the work happens at build time, and the browser only ever receives class names and CSS. *** To learn what motivated this design, read [Why Plumeria?](/docs/why-plumeria). For integration with bundlers and the full API, see the [API reference](/docs/api-reference) and [Installation](/docs/getting-started/installation). This site is built with Plumeria. The documentation app lives in the same repository and depends on the workspace packages, so every release is exercised here — and every experiment is tried here — before it ships. --- # Testing Source: https://plumeria.dev/docs/testing Three questions get asked of a style, and each has its own answer. What did it compile to. Does the component that uses it behave. Does the page it renders actually look right. ## What a style compiles to [#what-a-style-compiles-to] The transform is a function. Give it a source string and it hands back the rewritten code and the stylesheet, with no component, no DOM and no bundler in between — the same thing you would otherwise read off a `console.log`, in a form you can assert on. ```js title="compile.test.js" const { unpluginFactory } = require('@plumeria/unplugin/factory'); const plugin = unpluginFactory(); const compile = async (source) => { const { code } = await plugin.transform(source, `${__dirname}/fixture.tsx`); const cssId = code.match(/import "(.+\.zero\.css)"/)[1]; return { code, css: plugin.load(cssId) }; }; test('two properties become two atoms', async () => { const { code, css } = await compile(` import * as css from '@plumeria/core'; const styles = css.create({ box: { padding: 16, color: 'red' } }); export const A = () => ; `); expect(code).toMatch(/className=\{"\S+ \S+"\}/); expect(css).toContain('padding: 16px'); expect(css).toContain('color: red'); }); ``` `fixture.tsx` does not have to exist; the path only tells the compiler where the module would sit. The example is written for Jest. Vitest wants `import { test, expect } from 'vitest'` and ESM in place of `require` and `__dirname`; `node:test` takes `test` from `node:test` and asserts through `node:assert`, having no `expect`. What is being called stays the same in all three. `@plumeria/unplugin/factory` and the default export of `@plumeria/turbopack-loader` are supported entry points for exactly this. The factory's hooks and the four properties the loader requires of its context are part of the published surface, and will not be changed under you. ### Next.js [#nextjs] In a Next.js project the loader is what you test. [`@plumeria/turbopack-loader`](/docs/api-reference/plugins/next-plugin) is what `withPlumeria` installs, on Turbopack and webpack alike, so a test that calls it compiles through the same thing the build does. It takes a webpack loader context rather than plugin hooks, which is six lines to stand up: ```js title="loader.test.js" const loader = require('@plumeria/turbopack-loader'); const fn = loader.default ?? loader; const compile = (source) => new Promise((resolve, reject) => { const ctx = { resourcePath: `${__dirname}/fixture.tsx`, async: () => (err, content) => (err ? reject(err) : resolve(content)), addDependency: () => {}, clearDependencies: () => {}, }; fn.call(ctx, source); }); test('the styling prop becomes a className', async () => { const code = await compile(` import * as css from '@plumeria/core'; const styles = css.create({ box: { padding: 16, color: 'red' } }); export const A = () => ; `); expect(code).toMatch(/className=\{"\S+ \S+"\}/); expect(code).not.toMatch(/classStyle/); }); ``` Add `@plumeria/turbopack-loader` to your dev dependencies rather than reaching it through the plugin. The loader returns the rewritten code, and writes its stylesheet only when `NODE_ENV` is `development` or `production`. A test run is neither, so it leaves that file alone and sees the class names but no CSS. Set `NODE_ENV=development` if the stylesheet is what you came for — writes are taken under a lock, so parallel workers do not lose rules — or read it from the factory's `load()` above, which keeps it in memory and touches nothing. ## Components [#components] Vitest runs on Vite, so it takes the plugin directly: ```ts title="vitest.config.ts" import { defineConfig } from 'vitest/config'; import react from '@vitejs/plugin-react'; import plumeria from '@plumeria/unplugin'; export default defineConfig({ plugins: [react(), plumeria.vite()], test: { environment: 'jsdom', }, }); ``` The component is compiled by the plugin, and the styling prop is gone by the time it reaches the DOM: ```html