Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Avoid bundling @d3/shape
See original GitHub issueLooking at @primer/components on bundlephobia, it’s massive (40kB min+gzip), and a big part of that is the @d3/shape dependency that is in the core bundle due to being used in the Donut component.
We will most likely not end up using the Donut component, so shipping all that code is a bit of a pain. Is there any chance that the d3 dependency could maybe be loaded asynchronously when needed or that the Donut component gets put into its own bundle?
EDIT: Found a workaround in #456 by importing specific components. It would still be good to see this solved by default.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Agree we don’t need it in Primer, this would likely be and app specific component.
If we do end up developing components that are useful for some GitHub apps and increase bundle size but also often not needed, then we could make an “addons” library so that folks can decide what to pull in or not. I don’t think we need to go down the path we did with Primer CSS but addons could be a good option to consider in future if needed.
I think this is a good candidate for pulling out into a separate bundle. In Primer CSS land this would be a “product” style rather than a “core” style; maybe we should have a
@primer/components/productbundle? /cc @broccolini