Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this plugin useful anymore? #11

Closed
1 task done
pepkin88 opened this issue Oct 29, 2024 · 4 comments
Closed
1 task done

Is this plugin useful anymore? #11

pepkin88 opened this issue Oct 29, 2024 · 4 comments

Comments

@pepkin88
Copy link

pepkin88 commented Oct 29, 2024

Issue type

question

Description

Hello.
I stumbled upon this issue lucide-icons/lucide#2295, which linked to this repo.
The readme of this package says:

In fact, a single import from "lucide-" will import all icons, not ideal for performance and bundle size.

I'm a bit skeptical of this claim. Is it actually true? Maybe it was true some time ago, but is it still?

Because in the Lucide's docs, they say:

Lucide is built with ES Modules, so it's completely tree-shakable.

Each icon can be imported as a Svelte component, which renders an inline SVG element. This way, only the icons that are imported into your project are included in the final bundle. The rest of the icons are tree-shaken away.

That is in the context of their examples of the suggested usage:

<script>
  import { Skull } from 'lucide-svelte';
</script>

<Skull />

They did suggest, that importing icons directly may improve build and load times, but didn't explain why.

They also warned against this kind of usage:

import * as icons from 'lucide-svelte';

which, understandably, is not tree-shakable, and will bundle all the icons.

Moreover, I tried using this plugin in my project and there was no difference in the amount of transferred JS code before and after the change. It is possible I installed it wrong, but I tried to follow the instruction in the readme.

Could you clear my confusion?
Thanks.

Special case

  • This is not a bug nor a feature request, I can't use other templates
@WarningImHack3r
Copy link
Owner

WarningImHack3r commented Oct 29, 2024

Hi there, thanks for opening this issue! It's true that I didn't really make things clear on that side, so let me try to clarify.

First off, I'd like to preface by saying that I'm not an expert at all on the subject of tree-shaking, ESM, bundling, etc. I read stuff about this very issue and based this plugin on my general knowledge and the conclusions I've made based on what I've experienced, that's it.

The readme of this package says:

In fact, a single import from "lucide-" will import all icons, not ideal for performance and bundle size.

I'm a bit skeptical of this claim. Is it actually true? Maybe it was true some time ago, but is it still?

It is. Again, I'm not an expert, so I'll prove my point with a real-life example.

Here's my advent-of-svelte project with this plugin, in dev mode (I use this one as an example, but it could be any project, really. I just happen to use it to try things out with the plugin):

with plugin
All of the icons are separate small imports, one for each (I have a lot in this project). I hover over the file so you can reproduce it in the DevTools with the path in Sources.

Now, without the plugin:

without plugin
Some icons are separately imported for some reason, but the big problem is here: this 313k-line-long file, containing all Lucide icons.

This latter is the one we want to avoid, and that gets generated, as I state in my README, once a single import is using the raw from "lucide-<framework>"; form.

This is the problem lucide-icons/lucide#1707 solved for Svelte: generating/dealing with this large useless file effectively slows down the Vite dev server. I've never really experienced it myself because I have a decently fast machine, but this PR speaks for itself.

But yeah: the issue is (AFAIK) dev-mode only and doesn't seem to affect bundle size, that's why you might not have felt it.

Because in the Lucide's docs, they say:

Lucide is built with ES Modules, so it's completely tree-shakable. [...]

They did suggest, that importing icons directly may improve build and load times, but didn't explain why.

They say it themselves right under the snippet you sent me:

For faster builds and load times, you can import icons directly from the lucide-svelte/icons directory:

<script>
  import AlertCircle from 'lucide-svelte/icons/alert-circle';
</script>

<AlertCircle color="#ff3e98" />

Direct imports give better performance in dev mode and while building in general, as it helps Vite figure out what to import and avoid having to tree-shake all of that.

They also warned against this kind of usage:

import * as icons from 'lucide-svelte';

which, understandably, is not tree-shakable, and will bundle all the icons.

Indeed

Moreover, I tried using this plugin in my project and there was no difference in the amount of transferred JS code before and after the change.

I'm not really sure what you mean by "the amount of transferred JS", though I can encourage you to try it out by yourself by inspecting the Sources in dev mode as I did above.

Could you clear my confusion? Thanks.

Hope these explanations helped, let me know if you have any further questions or if I made any mistakes somewhere!

@pepkin88
Copy link
Author

pepkin88 commented Oct 29, 2024

Ah, OK, now I understand.
My confusion stemmed from my assumption, that the gains are in the production build, not in dev mode.
Indeed, in dev mode, all icons are imported.

I'm not really sure what you mean by "the amount of transferred JS", though I can encourage you to try it out by yourself by inspecting the Sources in dev mode as I did above.

I meant that in the network tab in Dev Tools, the summary "... MBs transferred" showed the same number before and after installing the preprocessor.
But I was checking the production build. In dev mode, the amount of downloaded code decreased quite a bit.

Also I looked at the building times and I see they are a bit shorter too. Great. Thanks for the plugin.

@WarningImHack3r
Copy link
Owner

Glad to hear! Thanks again for posting :)

@WarningImHack3r
Copy link
Owner

Just updated the README with corrections and a link to my answer from here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants