Files
4b3f93d9d0 feat(@lucide/solid): Support for Solid 2.0 RC (#4751)
* 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>
2026-10-02 19:02:20 +02:00

37 lines
1.8 KiB
Markdown

# Lucide Solid 2 integrations
These fixtures exercise the built `@lucide/solid` package in a real Solid 2 (release candidate) consumer app.
The `vite` fixture was scaffolded with the Solid 2.0 `basic` template:
```sh
npm create solid@latest -- --solid -t basic --ts
```
It keeps the template's turnkey client mode (`@solidjs/vite-plugin` with `start: true`, `filesystem-routing` and `@solidjs/router`), with the demo pages replaced by the icon showcase. The template's tooling versions are aligned with the workspace: TypeScript 6 and the workspace's pinned Vitest 4.
There is no SolidStart fixture yet, because SolidStart still targets Solid 1. The Solid 1 fixtures for `lucide-solid` live in [`../lucide-solid`](../lucide-solid).
Every fixture runs three checks:
- a framework production build;
- TypeScript with `noEmit`;
- Vitest Browser Mode in Chromium.
From the repository root, install Chromium once and run the complete suite:
```sh
pnpm --filter @lucide/integration-solid-2-vite exec playwright install chromium
pnpm test:integrations:solid-2
```
The fixtures depend on `@lucide/solid` through `workspace:*`, but import only its public package entry points. The root command builds `@lucide/solid` before running any consumer checks.
## Two TypeScript projects per fixture
`tsconfig.json` typechecks the fixture's own sources with `skipLibCheck: true`.
`tsconfig.declarations.json` compiles only `src/IconShowcase.tsx` (the file that imports the public entry points) with `skipLibCheck: false` and no ambient `types`. This makes `tsc` read the declarations shipped in `dist/types`, so a `.d.ts` that points at a file the build never emitted fails the check. Both run under `pnpm typecheck`.
`file-routes.d.ts` is generated by `filesystem-routing` on every build and is committed so `tsc` can resolve `virtual:file-routes` before a build has run.