2: "essential for medium to large-scale projects". Yes if you are using * to import a core library you are asking for trouble in your bundler when used with open source libraries on large projects. Your app might only need certain parts of a library, but asking for * can pull in TONS of code you arent even using. This is bad advice.
I am a full-stack developer and love coding and tooling. At my work, I am often the person who is developing and setting up dev and production environments.
Ahh I see I read it wrong. OK gotcha this is about easily creating a huge index for people to lazily get everything for your libs. But it still begs the question that it's not a good practice when large libraries can dump tons of code to importers who may only want a subset of code. Tree shaking doesn't work when you go to an index file and splat the whole thing.
Typically most libraries put a ton of components in their base export index for ease of importing their exports, possibly using the strategy outlined in #2. From an import perspective I find it best to find the folders where each component is located vs using an index. I've seen cases where one person imports an icon using * and imports a Meg or two of svg icons. I update it to just the icon we need and trim the fat and reduce the bundle size.
Most examples of using libraries use this lazy mode of * at the index of the library to get things done quick with example hello world usages of the libs. When sometimes if the package has a lot of components and moving parts it's best to find the folders for each thing you need and target that one vs importing everything in an index file.
I hate index files after they have screwed my bundle size so many times and I spend hours removing index references to get the specific components the callers of the library needed.
Agree and we can use vscode extensions such as "Import cost" to check how much code is getting imported while using this kind of exports.
I think using named exports to just import necessary part/functions from files exported like this wont be an issue.
Hi I am Sufian Mustafa an experienced web developer, who is continually exploring and mastering new web technologies. Sharing my learning journey through insightful posts to assist fellow developers.
Thank you so much for your thoughts! Your concern about using * to import an entire library is especially valid in large projects. ð︸ You are right; It may cause unnecessary bloat and affect the overall performance of the application.
The importance of the "export package" in my articles is more related to ease of import in project components and aims to improve organization and readability. However, I completely agree that caution should be exercised, especially when dealing with open source libraries.
For large projects, selecting only appropriate elements from the library is a best practice for optimization and keeping content lean and efficient. ðYour comments add value and I welcome the opportunity to delve deeper into this area.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
2: "essential for medium to large-scale projects". Yes if you are using * to import a core library you are asking for trouble in your bundler when used with open source libraries on large projects. Your app might only need certain parts of a library, but asking for * can pull in TONS of code you arent even using. This is bad advice.
But it is not about the import it is about the export. This shouldn't be an issue?
Ahh I see I read it wrong. OK gotcha this is about easily creating a huge index for people to lazily get everything for your libs. But it still begs the question that it's not a good practice when large libraries can dump tons of code to importers who may only want a subset of code. Tree shaking doesn't work when you go to an index file and splat the whole thing.
Typically most libraries put a ton of components in their base export index for ease of importing their exports, possibly using the strategy outlined in #2. From an import perspective I find it best to find the folders where each component is located vs using an index. I've seen cases where one person imports an icon using * and imports a Meg or two of svg icons. I update it to just the icon we need and trim the fat and reduce the bundle size.
Most examples of using libraries use this lazy mode of * at the index of the library to get things done quick with example hello world usages of the libs. When sometimes if the package has a lot of components and moving parts it's best to find the folders for each thing you need and target that one vs importing everything in an index file.
I hate index files after they have screwed my bundle size so many times and I spend hours removing index references to get the specific components the callers of the library needed.
Agree and we can use vscode extensions such as "Import cost" to check how much code is getting imported while using this kind of exports.
I think using named exports to just import necessary part/functions from files exported like this wont be an issue.
@sufian Nice article bro , learned a lot!
Thank you so much for your thoughts! Your concern about using * to import an entire library is especially valid in large projects. ð︸ You are right; It may cause unnecessary bloat and affect the overall performance of the application.
The importance of the "export package" in my articles is more related to ease of import in project components and aims to improve organization and readability. However, I completely agree that caution should be exercised, especially when dealing with open source libraries.
For large projects, selecting only appropriate elements from the library is a best practice for optimization and keeping content lean and efficient. ðYour comments add value and I welcome the opportunity to delve deeper into this area.