-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Misc: Bundlesize plugin #189
Comments
@tlwr Good suggestion. There is also Size Limit which is an npm module that we could work into the build process. I think there is a lot to be gained from analysing our dependencies, but I don't really want to enforce a hard size limit. Depending on the benefits, a large set of dependencies might be worth it. I would rather build an architecture that allows for lots of dependencies but doesn't load them all at once, like the module system in #173. It would be good to run these size tests over each of the compiled modules though, as they may be importing more than they need. Let's wait until #173 is merged and then look into this. |
I'm going to close this for now as I don't want to restrict module sizes at the moment. Code weight is still an important aspect for this project, but I don't want to set specific limits. Each new library needs to be considered on its merits. |
Update sl.json
I came across siddharthkp/bundlesize in my GH feed. It allows you to cap the size of your project's bundled artifacts, either for use in CLI scripts, or in a CI pipeline.
For example (from their readme):
Given that everything goes through Travis, and we've frequently discussed artifact sizes, it would make sense for us to have a helper that clarified the current situation. I think bundlesize would be a good solution.
If we want this added then I'll do it and make a PR.
The text was updated successfully, but these errors were encountered: