It's definitely easy to forget about peer dependencies, which is why I'll often just spin up a Vite project and examine the actual build output to be certain ab

It's definitely easy to forget about peer dependencies, which is why I'll often just spin up a Vite project and examine the actual build output to be certain about bundle sizes. To be fair to React though, in any production Preact app you'll probably end up pulling in either Preact Hooks or Preact Signals, which will add a few kb (unless you're using class components), but Preact Hooks is still only 3.7kb [1]. In the case of lit, I think lit-html actually is a direct dependency of lit (unless I'm reading it wrong)? In the composition section at the bottom of lit's Bundlephobia page it says lit-hmtl makes up 46.1% of lit's bundle size. The one thing you do have to remember about lit though is that if you're server side rendering you'll also need the @webcomponents/template-shadowroot polyfill, and @lit-labs/ssr-client/lit-element-hydrate-support.js [2]. I agree that Bundlephobia needs a peer dependencies mode. It still might be tough to be exhaustive about these things because react-dom depends on react as a peer, but confusingly the reverse is not true, because even though almost everyone is using react with react-dom, you could technically render to a different target (e.g. Ink uses react to render terminal UIs). Bundlephobia would need to be aware of packages that are so commonly used together that they're de facto peer dependencies, even if they're not de jure peer dependencies. [1] https://unpkg.com/browse/preact@10.19.3/hooks/dist/ https://unpkg.com/browse/preact@10.19.3/hooks/dist/ [2] https://lit.dev/docs/ssr/client-usage/ https://lit.dev/docs/ssr/client-usage/