You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to "Large bundles and broken tree-shaking in Shared", there may be some cases where one shared module size is extremely large. In these cases using something like button on page 1 can lead to downloading whole big heavy package like drag'n'drop library which is intended for page 2
Solution
It would be nice to check total external packages size a reexported file uses. I am not sure, is it possible technically, so I just share the idea
Some points
Using the same way as Import Cost VSCode Extension for calculating packages sizes of some module (AST based approach)
export { Button } from './button'
export { DatePicker } from './date-picker'
export { CodeEditor } from './code-editor' // 4mb is quite heavy so linter will show warning
The text was updated successfully, but these errors were encountered:
That's an interesting idea, thanks! Would be interesting to explore this from the performance perspective. Another question is how relevant this diagnostic is for modern bundlers like Vite or esbuild. We should do some testing here to identify if this rule would actually help people avoid excessively large bundles due to FSD's public API rules.
Problem
According to "Large bundles and broken tree-shaking in Shared", there may be some cases where one shared module size is extremely large. In these cases using something like button on page 1 can lead to downloading whole big heavy package like drag'n'drop library which is intended for page 2
Solution
It would be nice to check total external packages size a reexported file uses. I am not sure, is it possible technically, so I just share the idea
Some points
Example
shared/ui/index.ts
The text was updated successfully, but these errors were encountered: