@yak/solid 0.0.0 → 0.1.0

package/README.md

@@ -1,23 +1,26 @@
 # @yak/solid
 
-SolidJS runtime for [yak](https://yak.js.org/): styled-components syntax, compiled to plain CSS at build time, with dynamic values driven by Solid's fine-grained reactivity.
+Styled-components syntax for SolidJS, compiled away at build time. Your CSS is extracted by the [yak](https://yak.js.org/) SWC compiler and what's left at runtime is a thin layer that fits Solid's model: components run once, and dynamic styles are driven by signals, not re-renders.
 
-> **Status: experimental.** `@yak/solid` targets Solid 2 (currently at RC) and tracks it closely. Expect breaking changes while Solid 2 stabilizes. Solid 1 is not supported. This includes SolidStart v2, which runs on Solid 1.
+> **Status: experimental.** `@yak/solid` targets Solid 2 (currently at RC) and tracks it closely. Expect breaking changes while Solid 2 stabilizes. Solid 1 is not supported, and neither is SolidStart v2, which still runs on Solid 1.
 
-## How it works
+## Why this fits Solid
 
-Like `next-yak`, the yak SWC compiler extracts your CSS at build time. At runtime only a tiny layer remains that merges class names and feeds dynamic values through CSS custom properties:
+Most CSS-in-JS libraries assume a re-rendering component model. `@yak/solid` doesn't. It works the way you'd expect Solid code to work:
 
-- Static styles become plain CSS classes. A static `styled.div` never subscribes to the theme and adds a single reactive `class` binding.
-- Dynamic interpolations (`${(props) => ...}`) become CSS variables set on the element's inline `style`. Updates flow through one memo per component: the element is never re-created, only its `class`/`style` bindings change, and only props actually used by the CSS re-run the memo.
+- **Static styles are just classes.** A `styled.div` with no interpolations compiles to a plain CSS class and a single reactive `class` binding.
+- **Dynamic styles are signals in, CSS variables out.** Interpolations like `${(props) => props.$angle}` become CSS custom properties on the element's inline `style`. All of them are computed in one memo per component. When a prop changes, the element is not re-created, only its `class`/`style` bindings update, and the memo only re-runs for props the CSS actually reads.
+- **No hidden subscriptions.** Reads inside interpolations are tracked like any other reactive read in Solid. If your CSS doesn't read `props.theme()`, it doesn't subscribe to the theme.
 
-## Usage
+## Getting started
 
 ```bash
 pnpm add @yak/solid
 pnpm add -D vite-plugin-solid@next
 ```
 
+Add the yak plugin before `solid()` in your Vite config:
+
 ```ts
 // vite.config.ts
 import { defineConfig } from "vite";
@@ -29,6 +32,8 @@ export default defineConfig({
 });
 ```
 
+Then write styled components the way you'd write them anywhere else. Prop-based interpolations are tracked reactively:
+
 ```tsx
 import { styled, css, keyframes } from "@yak/solid";
 
@@ -46,9 +51,7 @@ const Hand = styled.div<{ $angle: number }>`
 `;
 ```
 
-Interpolation functions re-run inside the component's style memo, so destructuring their parameter (`${({ $angle }) => ...}`) is also safe. These docs use the `props` style because it matches Solid's conventions.
-
-The `css` prop works on all intrinsic elements (uses Solid's `class` attribute):
+The `css` prop works on every intrinsic element and maps to Solid's `class` attribute:
 
 ```tsx
 <p
@@ -72,7 +75,7 @@ declare module "@yak/solid" {
 }
 ```
 
-`useTheme()` returns an accessor, like a signal getter. Call it where the value is used. That read subscribes the surrounding scope to theme changes:
+`useTheme()` returns an accessor, like a signal getter. Call it where the value is used. That read is what subscribes the surrounding scope to theme changes:
 
 ```tsx
 import { styled, useTheme, YakThemeProvider } from "@yak/solid";
@@ -92,7 +95,7 @@ function Toolbar() {
 </YakThemeProvider>;
 ```
 
-The package also exports the context itself for native composition, e.g. overriding the theme for a subtree. In Solid 2 a context is its own provider and takes an accessor:
+The theme context itself is exported too, so you can compose it natively, e.g. to override the theme for a subtree. In Solid 2 a context is its own provider and takes an accessor:
 
 ```tsx
 import { createMemo } from "solid-js";
@@ -105,21 +108,25 @@ function InvertedSection(props) {
 }
 ```
 
-## Differences to next-yak (React)
+## Coming from next-yak or React?
 
-- `useTheme()` returns an accessor: read `theme().highContrast`, not `theme.highContrast`. The same applies to `props.theme()` in interpolations and `.attrs()`.
-- `class` instead of `className` (Solid convention), also inside `.attrs({ ... })`.
-- No jsx-runtime export: Solid compiles JSX natively. The css prop types activate by importing `@yak/solid`.
-- Components run once. Solid's reactivity drives dynamic styles instead of re-renders.
-- `foldStatic` is off by default (see [Static folding](#static-folding-opt-in) below).
+If you've used `next-yak`, the API is the same with a few Solid-shaped differences:
 
-## Static folding (opt-in)
+- `useTheme()` returns an accessor: read `theme().highContrast`, not `theme.highContrast`. The same applies to `props.theme()` in interpolations and in `.attrs()`.
+- `class` instead of `className`, including inside `.attrs({ ... })`.
+- No jsx-runtime export. Solid compiles JSX natively, which means the `css` prop types activate simply by importing `@yak/solid`.
+- Components run once. There is no re-render to recompute styles and Solid's reactivity handles it.
 
-`yak({ foldStatic: true })` additionally folds usages of fully static components into plain elements at build time, removing their wrapper components. It is off by default as we didn't test all the edge-cases and can't guarantee it works correctly everywhere.
+## How it works
+
+Like `next-yak`, the yak SWC compiler extracts your CSS at build time. At runtime only a tiny layer remains that merges class names and feeds dynamic values through CSS custom properties:
+
+- Static styles become plain CSS classes. A static `styled.div` never subscribes to the theme and adds a single reactive `class` binding.
+- Dynamic interpolations (`${(props) => ...}`) become CSS variables set on the element's inline `style`. Updates flow through one memo per component: the element is never re-created, only its `class`/`style` bindings change, and only props actually used by the CSS re-run the memo.
 
 ## Requirements
 
-- `solid-js` >= 2.0.0-rc.0 and `@solidjs/web` >= 2.0.0-rc.0
+- `solid-js` >= 2.0.0-rc.5 and `@solidjs/web` >= 2.0.0-rc.5
 - `vite-plugin-solid` >= 3.0.0-next (the Solid 2 line, npm tag `next`)
 - `yak-swc` with yak-package auto-detection (bundled as a dependency, version released together with this package or newer)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yak/solid",
-  "version": "0.0.0",
+  "version": "0.1.0",
   "description": "SolidJS runtime for yak: styled-components syntax, compiled to plain CSS at build time. Targets Solid 2.",
   "keywords": [
     "css-in-js",
@@ -71,30 +71,23 @@
   "publishConfig": {
     "access": "public"
   },
-  "scripts": {
-    "build": "tsdown",
-    "test": "vitest run",
-    "test:watch": "vitest",
-    "test:types": "tsc -p tsconfig.json && tsc -p runtime/__tests__/tsconfig.json",
-    "prepublishOnly": "pnpm build && pnpm test && pnpm test:types"
-  },
   "dependencies": {
-    "@babel/parser": "catalog:core",
-    "@swc/core": "catalog:core",
-    "yak-swc": "workspace:*"
+    "@babel/parser": "8.0.0",
+    "@swc/core": "1.15.43",
+    "yak-swc": "9.9.0"
   },
   "devDependencies": {
-    "@solidjs/web": "catalog:solid",
-    "@testing-library/jest-dom": "catalog:dev",
-    "@types/node": "catalog:dev",
-    "jsdom": "catalog:dev",
-    "solid-js": "catalog:solid",
-    "tsdown": "catalog:dev",
-    "typescript": "catalog:dev",
-    "vite": "catalog:dev",
-    "vite-plugin-solid": "catalog:solid",
-    "vitest": "catalog:dev",
-    "yak-internals": "workspace:*"
+    "@solidjs/web": "2.0.0-rc.5",
+    "@testing-library/jest-dom": "6.9.1",
+    "@types/node": "26.0.1",
+    "jsdom": "29.1.1",
+    "solid-js": "2.0.0-rc.5",
+    "tsdown": "0.22.3",
+    "typescript": "6.0.3",
+    "vite": "8.1.1",
+    "vite-plugin-solid": "3.0.0-next.27",
+    "vitest": "4.1.9",
+    "yak-internals": "0.0.0"
   },
   "peerDependencies": {
     "solid-js": ">=2.0.0-rc.5",
@@ -104,5 +97,11 @@
     "vite": {
       "optional": true
     }
+  },
+  "scripts": {
+    "build": "tsdown",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "test:types": "tsc -p tsconfig.json && tsc -p runtime/__tests__/tsconfig.json"
   }
-}
+}

package/runtime/__tests__/typeTest.tsx

@@ -59,4 +59,13 @@ const override = <YakThemeContext value={() => ({})}>{cssPropUsage}</YakThemeCon
 // @ts-expect-error - the context value must be an accessor, not a theme object
 const invalidOverride = <YakThemeContext value={{}}>{cssPropUsage}</YakThemeContext>;
 
-export { buttonUsage, customUsage, withAttrsUsage, Spinner, provider, themeValue, override, invalidOverride };
+export {
+  buttonUsage,
+  customUsage,
+  withAttrsUsage,
+  Spinner,
+  provider,
+  themeValue,
+  override,
+  invalidOverride,
+};