Thanks for the PR! I was considering using some dedicated tool for this (i've looked briefly into
size-limit too). I'm not opposed to using one - especially I'd like to chose 1 tool and configure more packages with it.
The problem I have is that it's IMHO those measurements are often hard to get right (each situation is different) and often they might misinform the people looking at them. I.e. I don't believe we should count webpack's runtime wrapper - this is not the cost of a module. Also I don't quite think
prop-types package should be counted here either - most people have it in their bundles anyway, so it wouldn't be an added cost. While I remove
propTypes now in production mode, it's not possible (at least I don't know how) to remove the
import 'prop-types' declaration because of ESM static nature.
I agree that one thing is what's the size of the module itself, one thing is what's the size of the module and its dependencies and I think both are valuable metrics.
Open question - I'm wondering how we should measure tree-shakeable libraries. Let's take
polished lib as an example - it's totally tree-shakeable so it's actual cost may vary A LOT, because it depends on the actual usage and not on what a library in question provides.
Don't take me wrong - I would very much like to chose some tool for the job. This answer is more of a discussion starter right now than a direct response to this PR.