Fixed export maps, types, and packaging for lucide-svelte

[AdrianGonz97]

Fixes #1284, fixes #1572

What is the purpose of this pull request?

• New Icon
• Bug fix
• New Feature
• Documentation update
• Other: Replaced Rollup and other deps

Description

This PR contains a number of fixes:

1. Simplified the current build system by replacing rollup and svelte-strip for the official @sveltejs/package CLI
   • this gets rid of the fully compiled svelte components and their respective source maps as they aren't necessary in svelte packages (which will also lessen the size of the overall package by a considerable amount)
2. Fixed the export conditions in the export map such that direct import paths resolve properly, leading to faster load times
   • (e.g. import Circle from "lucide-svelte/icons/circle" will be faster to load than import { Circle } from "lucide-svelte")
3. Fixed types for users that use moduleResolution: "NodeNext" in their tsconfig.json
4. Updated the deprecated svelte.JSX namespace types for element types sourced from svelte/elements

Additional Notes

• I noticed that the package included fully compiled svelte components (i.e. everything inside of the esm directory in dist are fully compiled vanilla JS components). Was there a particular reason for this? It's not really the recommended way of packaging Svelte components.

• While updating the types, I noticed that the icons were meant to extend the attributes of an SVGElement like this in the build script:

interface IconProps extends Partial<svelte.JSX.SVGProps<SVGSVGElement>> {
  color?: string
  size?: number|string
  strokeWidth?: number|string
  absoluteStrokeWidth?: boolean
  class?: string
}

But, currently in the latest release, if you examine any of the icon's prop types on the end user's side, they only show the types for color, size, strokeWidth, etc, and none of the attributes that belong to SVGElement.

This doesn't seem intentional, so I could add a fix for this too by extending IconProps with SVGAttributes<SVGSVGElement> instead in types.ts.

While it would provide the proper types now, it would also flood the autocompletions with the SVGElement's attributes, making color, size, strokeWidth, etc, less noticeable:

Just wanted to note this as something to be aware of! Please let me know if I should apply the fix!

Before Submitting

• I've read the Contribution Guidelines.
• I've checked if there was an existing PR that solves the same issue.

[AdrianGonz97]

I've gone ahead with adding the fix for the icon props type.

This PR is all set and ready to go👍

[ericfennis]

@AdrianGonz97 Great work, this works great! I've tested it.
It works really well with SvelteKit.

Only Svelte with Vite is still loading all the component files from the index file. But yeah that's maybe more a Svelte/Vite problem than from us.

I've couple of questions.
With current build setup our license is bundled with the code, we use the rollup-plugin-license for this, is it possible to add custom rollup plugins in the build process?

And I noticed there is a .svelte-kit directory, do we need to ship this when we release the package?

[AdrianGonz97]

@ericfennis Thanks for taking a look!

Only Svelte with Vite is still loading all the component files from the index file. But yeah that's maybe more a Svelte/Vite problem than from us.

Correct! Vite eagerly loads all of the dependencies of a loaded module, which leads to slowdowns if the loaded module is a very large barrel file, such as our index.ts. Being able to import icons with direct imports, such as import Circle from "lucide-svelte/icons/circle", prevents Vite from performing this "optimization".

With current build setup our license is bundled with the code, we use the rollup-plugin-license for this, is it possible to add custom rollup plugins in the build process?

It looks like this rollup plugin is limited to only prepending the license comment to .js files. If you look at the latest version of the package, you'll see that the license isn't present in any of the .svelte or .d.ts files here.

As a fix, I could write a simple build script that could just prepend the license to all the files in dist with the appropriate comment syntax.

And I noticed there is a .svelte-kit directory, do we need to ship this when we release the package?

Nope! Not necessary at all, it's just a build artifact and it shouldn't be included in the package.

[AdrianGonz97]

I've created the build script under scripts/addLicense.mjs so that it prepends the license to all applicable distributed files (.svelte and .d.ts included!). Let me know what you think!

[huntabyte]

Thanks for tackling this @AdrianGonz97, this is going to be a gamechanger for dev servers everywhere 😂

[ericfennis]

Nice work @AdrianGonz97!
Great solution, This almost ready to go!

The banner license text should be updated to latest text.

[isker]

@AdrianGonz97 I think your script to insert the license comment at the top of all of the svelte components has created some of the infamous svelte whitespace problems when rendering icons inline.

Check out an example from my SvelteKit site. See how the ChevronRight jumps around between SSR and CSR? You can disable JS to get a better look. All this extra whitespace is to the left of the chevron:

Relevant source code: https://github.com/isker/neogrok/blob/d36fe3efa5fc792a53b89a3d41036706ccafacdd/src/routes/(search-page)/search-results-file-header.svelte#L29-L32

When I go into node_modules and remove the license comment at the top of chevron-right.svelte and Icon.svelte, the problem goes away. (If I only do one of those two, the size of the whitespace is reduced by half 🌞.) Also goes away if I downgrade to lucide-svelte 0.300.0, which is the last version before this PR landed.

Would you be willing to fix this? I'd think the license has to stop being in an HTML comment 😞. Maybe it can go into a JS comment instead, but you'd have to put it inside the script tag then.

If not, I will probably try to do it.

[AdrianGonz97]

@isker Thanks for pointing this out. This game of whackamole never seems to end 😅. Hopefully this is the last one.

I have an idea for a fix that should still preserve the license comment. Will implement it when I get a chance.

[WarningImHack3r]

@AdrianGonz97 @huntabyte @ericfennis I made a Vite preprocessor for this