mirror of https://github.com/lucide-icons/lucide.git synced 2026-11-13 13:48:26 +00:00

Files

T

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

949 B

Raw Permalink Blame History

title, description

title	description
Aliased Names - Solid	Learn about the different import name styles available for Lucide icons in your Solid project and how to choose the one that best fits your needs.

Aliased Names

Some icons have multiple names. This is because we sometimes choose to rename them to make them more consistent with the rest of the icon set, or the name was not generic. For example, the edit-2 icon is renamed to pen to make the name more generic, since it is just a pen icon.

Beside these aliases, Lucide also includes prefixed and suffixed names to use within your project. This is to prevent import name collisions with other libraries or your own code.

// These are all the same icon
import {
  House,
  HouseIcon,
  LucideHouse,
} from "lucide-solid";

Turn off autocomplete in your IDE

{
  "js/ts.preferences.autoImportFileExcludePatterns": [
    "lucide-solid",
  ]
}

949 B Raw Permalink Blame History

Aliased Names

Turn off autocomplete in your IDE

949 B

Raw Permalink Blame History