@livestorm/ui-vue 2.0.4 → 3.0.0

package/README.md

@@ -48,17 +48,20 @@ pnpm add @livestorm/ui-vue
 
 ## Tailwind CSS setup
 
-Components use Tailwind utility classes (including the `i-ls-*` icon classes), so your app needs to run Tailwind and scan the library. In your Tailwind entry CSS:
+Components use Tailwind utility classes (including the `i-ls-*` / `i-ph-*` icon classes), so your app needs to run Tailwind and scan the library. In your Tailwind entry CSS:
 
 ```css
 @import "tailwindcss";
 @import "@livestorm/ui-tokens/output/supernova/index.css";
-@import "@livestorm/ui-icons/icons-tailwind-utilities.css";
+@plugin "@livestorm/ui-icons/tailwind";
+@import "@livestorm/ui-icons/base.css";
 
 /* Generate the utility classes used by ui-vue components */
 @source "../node_modules/@livestorm/ui-vue/dist";
 ```
 
+The icon plugin serves the custom Livestorm set (`i-ls-<name>`) and [Phosphor](https://phosphoricons.com) (`i-ph-<name>`, `regular` and `-fill` weights). Icon names must appear as complete literals in scanned sources — never compose them at runtime.
+
 > [!WARNING]
 > Components rely on the design-token utilities these two imports produce (`bg-actions-primary-idle`, `i-ls-*`, ...). Those class names live in the component code, not in the shipped stylesheet, so if your own theme resets the token namespace (for example `--color-*: initial` in an `@theme`), Tailwind silently stops generating them and components render unstyled — no error, no warning. Keep the Livestorm token imports alongside your palette instead of resetting all colors.
 
@@ -117,7 +120,7 @@ import { setTranslator } from '@livestorm/ui-vue/integrations'
 setTranslator((key) => myI18n.t(`ui-vue.${key}`))
 ```
 
-On an SSR server rendering a locale per request, provide the translator on the app instance instead — `setTranslator` is process-wide state shared by concurrent requests:
+On an SSR server, provide the translator on the app instance instead — `setTranslator` is process-wide state shared by concurrent requests, and without a translator the server falls back to English (it cannot read `<html lang>`). For a non-English SSR app this is the difference between hydrating correct labels and keeping English aria-labels:
 
 ```ts
 import { UI_VUE_TRANSLATOR } from '@livestorm/ui-vue/integrations'
@@ -137,7 +140,7 @@ import { UiButton, UiTextField, UiInputSelect } from '@livestorm/ui-vue'
 
 ```vue
 <template>
-  <UiButton variant="cta" color="primary" icon="i-ls-check">
+  <UiButton variant="cta" color="primary" icon="i-ph-check">
     Click me
   </UiButton>
 </template>
@@ -159,7 +162,7 @@ registerComponents(app, 'Ls')    // <LsButton>, <LsTextField>, ...
 | `@livestorm/ui-vue/style` | Base stylesheet (import once) |
 | `@livestorm/ui-vue/fonts` | Optional: loads Inter from Google Fonts (skip it if you self-host) |
 | `@livestorm/ui-vue/components-vite` | `registerComponents` for global registration |
-| `@livestorm/ui-vue/integrations` | Toast helpers (`openToast`, ...) |
+| `@livestorm/ui-vue/integrations` | Toast helpers (`openToast`, ... — call client-side only: toast state is per-process on a server) and translation wiring (`setTranslator`, `UI_VUE_TRANSLATOR`) |
 | `@livestorm/ui-vue/layouts` | Layout components such as the toast container |
 | `@livestorm/ui-vue/utils` | Helpers (`useCopyToClipboard`, `useRouteQueryModel`, ...) — the one entry that requires `vue-router` |
 | `@livestorm/ui-vue/responsive` | Optional responsive plugin |