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.
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!