Make it easy to fork and release a modified version of lucide.

[jguddas]

Package

• lucide
• lucide-angular
• lucide-flutter
• lucide-preact
• lucide-react
• lucide-react-native
• lucide-solid
• lucide-svelte
• lucide-vue
• lucide-vue-next
• Figma plugin
• all JS packages
• site

Description

I would love if I could press fork and with minimal effort release my changes to NPM as new packages.

Use cases

• People want to build their own icon library from scratch (fresh start with 0 icons but all the boilerplate your heart desires)
• People want to extend lucide with icons that won't make it into lucide i.e., praying-hands, poo-with-eyes, etc.
• People creating custom variants of lucide icons (what I want to do)

Checklist

• I have searched the existing issues to make sure this bug has not already been reported.

[jguddas]

@danielbayley would you also be interested in this?

[ericfennis]

Ok, I've maybe a good idea for this. I don't want to call it a "fork". But more an "extended" library version of lucide.

Creating icon components from icon nodes & second repo idea

We could add a special function to each package named e.g: createFromIconNodes. Which creates icon components from icon nodes. We already have a similar function in the library but that is for single use.

// React example
import { createFromIconNodes, createLucideIcon } from '@lucide/react';
import iconNodes from './myIconNodes';
import { PooWithEyes }  from '@lucide/extended';

// This function will create object components, which can be destructed as well.
const myIcons = createFromIconNodes({
   ...iconNodes,
   PooWithEyes
});

// Alt: Single icon component generation, every library has already this function.
const PooWithEyesIcon = createLucideIcon('PooWithEyes', PooWithEyes)

// Now you can use the created icons in your React components
function MyComponent() {
  return (
    <div>
      <myIcons.MyIcon1 />
      <myIcons.MyIcon2 />
      <myIcons.MyIcon3 />
      <myIcons.PooWithEyes />
      {/* ... */}
    </div>
  );
}

With this, we could make a second repo for all these extra icons that don't make the "main" library. The rules and acceptance criteria of this repo will be more relaxed.

Another useful usecase is: for the deprecation of the brand icons in the library. We could move this to a separate library: @lucide/brands. This library will contain all the brand icons we currently have in our library, but then in the form of icon nodes.

Why not do this with all our icons/packages?

Yeah, probably some people will think of this. The basic answer: is developer experience. Importing icons as components is super easy to work with all these libraries. Changing all our APIs to this format will create a lot of extra steps for devs. So this API should be more for special occasions.

Custom icons

This could be a separate library containing useful functions like createIconNodeFromSVG. That for example converts your svgcode in an icon node. So you can use the Lucide API with your own icons.

For Example

import { createIconNodeFromSVG } from '@lucide/utils'

const myIconNode = createIconNodeFromSVG('<svg> .... </svg>');

export const MyIconComponent = createLucideIcon('MyIcon', myIconNode)

But under the hood, it will basically do this:

Svgcode -> IconNode -> SvgCode

Let me know what you think of this idea.

[olaf-k]

I'm biased because of #1594 but that looks like a great idea.

[jguddas]

A nice approach could be to create a release action that builds the package and pushes it to NPM for you.

https://github.com/jguddas/icon-library-structure-example/blob/main/.github/workflows/release.yml#L26

[danielbayley]

@danielbayley would you also be interested in this?

@jguddas 100%!