* Updates needed to support Solid 2
* Switch to the next tag
* feat(packages): add `@lucide/solid` package for Solid 2
Solid 2's API is a breaking change from Solid 1 and is still an RC, so
`lucide-solid` stays on Solid 1 (`solid-js: ^1.4.7`) untouched and Solid 2
support ships as a new `packages/solid` package named `@lucide/solid` —
the same scheme already used by `@lucide/svelte` and `@lucide/angular`.
The package is a copy of `lucide-solid` on the `@lucide/shared` build
architecture, ported to Solid 2:
- `splitProps` -> `omit`, `solid-js/web` -> `@solidjs/web`,
`JSXElement` -> `Element`, `Context.Provider` -> `<Context value>`
- `jsxImportSource` is `@solidjs/web` in tsconfig, the esbuild step and
`ts.createProgram`; rollup externals drop the removed `solid-js/store`
- `vite-plugin-solid` -> `@solidjs/vite-plugin`
- tests keep upstream's coverage with two Solid 2 adaptations: boolean
attribute literals must be strings (`aria-hidden="false"`), and writes
are batched so the reactivity tests need a `flush()` before asserting
Rendered output is unchanged — the snapshots are byte-identical to
`lucide-solid`'s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(solid): fix React leftovers in the Solid guide
The Solid guide was derived from the React guide and three things were
not carried across:
- `advanced/typescript.md` still told readers the types are for "a
TypeScript React project"
- its `LucideIcon` example kept React's destructured-props signature.
The `: ButtonProps` annotation had also been dropped in the copy, so
`ButtonProps` was declared but unused and the parameters were
implicitly `any`. Destructuring props breaks reactivity in Solid —
verified: with `({ icon: Icon, label })` a changing `label` never
reaches the DOM, while `props.label` updates correctly.
- `advanced/aliased-names.md` had an orphaned `###` heading; its parent
`## Choosing import name style` was dropped during the conversion
because it documents React-only subpath exports.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: type the shared Sandpack wrapper with `SandpackProps`
The base Sandpack wrapper declared its props as
`FunctionalComponent<LucideProps>` with `LucideProps` imported from
`@lucide/vue`, which has nothing to do with a Sandpack embed. None of
the props the markdown plugin actually passes (`template`, `files`,
`options`, `customSetup`, `theme`) were declared, so they only reached
the inner `<Sandpack />` via Vue's fallthrough attributes.
Declare `SandpackProps` from `sandpack-vue3` instead and forward them
explicitly. This also removes the `@lucide/vue` import that made every
framework guide — including the Solid one, which uses this wrapper
directly — appear to reference the Vue package.
Verified with a full `vitepress build`: each framework guide's chunk
still carries its own template (react/vue/vite-svelte/vanilla/
vite-solid) and all five props reach the component.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(solid): document the Solid 2 flavour in the getting started guide
The Solid guide teaches `lucide-solid` throughout (64 references), so
the one-line note about `@lucide/solid` left Solid 2 readers on a page
whose every install command and live example is Solid 1 — and the
packages list points `@lucide/solid` at this same page.
Replace that note with a "Using Solid 2?" callout holding its own
tabbed install group, the import-specifier swap, and a table of the
Solid 2 changes that affect code written around Lucide (`@solidjs/web`,
`jsxImportSource`, `splitProps` -> `omit`, `<Ctx value>`), linking out
to Solid's own migration guide for the rest.
The claim that both packages expose the same components and props is
checked, not assumed: `dist/types/lucide-solid.d.ts` is identical
between the two packages, and the only differences anywhere in the
public type surface are Solid's own renames (the `JSX` namespace source
and `JSXElement` -> `Element`).
Keeps one guide section for both packages, matching how upstream
handles the two Svelte packages.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(solid): port lucide-solid to Solid 2
- Icon/context/types use Solid 2 APIs: omit() instead of splitProps(),
Dynamic and JSX types from @solidjs/web.
- solid-js / @solidjs/web 2.0 (rc) as peer and dev dependencies,
babel-preset-solid 2; rollup and tsconfig updated to match.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Add integration test
* Update rollup file
* Fix tests
* Revert lucide-solid changes
* update lockfile
* Fix docs
* Format code
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Eric <eric.fennis@gmail.com>
* test(lucide-solid): add Vite and SolidStart integration fixtures
Mirror the `lucide-react` integration suite for `lucide-solid`. Both
fixtures are scaffolded by `pnpm create solid` and consume the built
package through its public entry points only:
- `integrations/lucide-solid/vite` (vanilla/basic template)
- `integrations/lucide-solid/solid-start` (solid-start-v2/basic template)
Each runs a production build, `tsc --noEmit`, and a Vitest Browser Mode
test in Chromium under a `check` script, wired into the new root
`test:integrations:solid` script and an `integration` job on the
`lucide-solid` workflow.
The showcase exercises the bare export, per-icon props, `LucideProvider`,
an alias against its canonical icon, and the `lucide-solid/icons/circle`
deep import. `lucide-solid` has no `DynamicIcon`, so the deep import
takes the place of the React fixtures' dynamic-icon block. The SolidStart
spec additionally navigates between two routes.
Both fixtures resolve the package through its `solid` export condition
and compile the raw JSX in `dist/source`; the SolidStart build bundles it
into the SSR server chunk.
Each fixture carries a second TypeScript project,
`tsconfig.declarations.json`, that compiles the showcase with
`skipLibCheck: false` so the declarations shipped in `dist/types` are
actually read. That catches a `.d.ts` pointing at a file the build never
emitted, which the app typecheck silently degrades to `any`.
`@solidjs/start@2` requires Vite 8 while the repository pins Vite 7, so
the SolidStart fixture is released from that pin by a parent-scoped
`'@lucide/integration-solid-solid-start>vite'` override. Only that
importer resolves to Vite 8; every other package stays on 7.3.6.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EAmVJZqdypLNwEFhCmfsPN
* fix(solid): align SolidStart fixture with Vite 7
* Upgrade vite dependency from 7.3.6 to 8.3.2
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Update README.md to clarify Vite overrides
Removed duplicate note about bug #4846 and added a section on Vite overrides.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* fix(docs): persist icon customizer settings
Persist icon color, size, stroke width, and absolute stroke width between page navigations and reloads.
Keep a shared icon style state across the homepage and icons page, clamp the homepage preview size to its supported range, and apply persisted absolute stroke settings after mount.
* fix(docs): avoid icon customizer hydration flicker
Initialize persisted icon settings synchronously and apply absolute stroke width before the first rendered state.
* fix(docs): restore icon styles before first paint
Apply stored icon styles from a head script before hydration, defer customizer visibility until mount, and render persisted switches on the client to avoid stale SSR classes. Keep absolute stroke state synchronized globally and cover prepaint initialization with regression tests.
* fix(site): persist icon customizer
* fix(packages/react): update vulnerable @tanstack packages
* fix(docs): persist icon customizer settings
Persist icon color, size, stroke width, and absolute stroke width between page navigations and reloads.
Keep a shared icon style state across the homepage and icons page, clamp the homepage preview size to its supported range, and apply persisted absolute stroke settings after mount.
* fix(docs): avoid icon customizer hydration flicker
Initialize persisted icon settings synchronously and apply absolute stroke width before the first rendered state.
* fix(docs): restore icon styles before first paint
Apply stored icon styles from a head script before hydration, defer customizer visibility until mount, and render persisted switches on the client to avoid stale SSR classes. Keep absolute stroke state synchronized globally and cover prepaint initialization with regression tests.
* fix(site): persist icon customizer
* fix(packages/react): update vulnerable @tanstack packages
* fix(site): generalize usePersistedIconStyle to reduce code duplication in icon customizers
* fix(site): home size slider now uses max="256", matching the sidebar
* fix(site): fix linting issues in iconStyleHead.js
* fix(site): make Switch.vue hydration safe
* fix(site): fix home icon customizer color input width
* fix(site): make home icon customizer not persistent
* fix(site): fix duplicate ids in sidebar icon customizer as well
* fix(site): various minor fixes to the customizer bl
* fix(site): revert "[default]" placeholder
---------
Co-authored-by: epifaniofrancisco <epifaniofrancisco03@gmail.com>
Mirror the lucide-react integration tests for `@lucide/vue`. Each fixture is
scaffolded with the framework's official generator (`pnpm create vue@latest`,
`pnpm create nuxt@latest`, `pnpm create vike@latest --vue`), trimmed of demo
boilerplate, and runs a production build, `vue-tsc`, and a Vitest Browser Mode
test in Chromium that renders the public `@lucide/vue` APIs (static icon,
per-instance props, `setLucideProps` context, alias vs canonical icon).
Nuxt is pinned to 4.4.8: 4.5.x requires Vite 8, which the workspace-wide
`vite: ^7.3.6` override does not allow.
Wire it up with a `test:integrations:vue` root script and an `integration`
job in the Lucide Vue workflow.
Claude-Session: https://claude.ai/code/session_01KmQsnSECZoNxh1GJ15BmdH
Co-authored-by: Claude <noreply@anthropic.com>
