Call for contributors and co-maintainers

Background

Bundlephobia’s been a passion project for me for close to a half a decade now. I’ve dedicated hundreds of hours to building it, addressing issues and maintaining infrastructure, databases etc and received a lot of indirect support and love from the OSS community at large.

When bundlephobia came into being, bundle size bloat due to 3rd party code was often seen as an unavoidable casualty of frontend development.

Over the years though, awareness here has grown multi-fold, and tools like editor plugins (e.g. import cost), similar sites such as packagephobia, bundlejs, package size information on npmjs.org etc have come into being (I’d like to think some of these were at least partly inspired by bundlephobia).

I have a lot of ideas for bundlephobia, and not enough time — a project like this needs a healthy community of contributors to survive the limitless abyss that is one person’s procrastination. You might have noticed issues piling up, and updates getting slower and less frequent.

The bugle

This is a call for co-maintainers and contributors. Bundlephobia is a project that is reasonably easy to contribute to and is widely known and used by those in the frontend community — you can create a big impact!

As a small means of expressing my gratitude, top contributors and maintainers will receive a token amount from Bundlephobia’s open collective fund for their effort and time.

Here are the following big themes I’m looking for help with. If you’re interested in any of themes add a reply to this post with what interests you, and a short blurb about how you plan to go about it.

Beginner friendly

Code health

1. ⌨️ Incremental typescript migration
2. 💅 Incremental migration from SCSS to CSS in JS (emotion), or CSS modules
3. ▲ Next JS upgrade to 12

Interface

1. 🌚 Dark mode Switch colors to be CSS variable based, so we can introduce themeing and dark mode support
2. 📺 Local CLI (powered by package-build-stats)

Intermediate

New Features

1. 👯‍♂️ Alternate package recommendations These haven’t been updated for a long time. We need to move these out of the main repository to manage issues better, and setup a more sustainable submission process
2. 👥 Package comparison Support new UI for N-way comparison of packages

Insights

Over time, bundlephobia’s been able to collect a lot of data on how dependencies in the NPM ecosystem have evolved over the last 5 years, and there might be interesting insights to be drawn regarding macro trends (think State of JS, but for JS dependencies)

Intermediate+

Bundling & Core

1. Support for multi-entry point packages Bundle size for packages that use the exports field to expose multiple entry points. This is different from treeshakeability of the main entry point.
2. Upgrade bundler to Webpack 5 / Parcel: Unlock performance, richer insights, align better with what people are using at large.
3. Inteligent sizing We can look at a project’s package.json / yarn.lock to understand exactly how much weight a new library might be bringing in. For example, a project that already uses d3, isn’t going to pay a lot of cost if they dropped in a d3-based charting library, vs. others might. Think of this to be similar to how caniuse.com can tailor usage for you if you upload your google analytics traffic share.

These are the main themes we want to work on, but open to considering others as well, so don’t hesitate if there’s something else that you’d like to help with.

With ❤️

[darasus]

Hello @pastelsky! I believe I can help with the migration to typescript but, would it make sense to migrate to functional components first? I think it would make the codebase more approachable.

@raulmarindev I don’t mind refactoring existing class components to functional components — though that shouldn’t be a pre-requisite for a typescript migration. The approachability of functional components vs class components is pretty subjective

IMO — there have been times I’ve felt the other one was more intuitive. But FC’s do seem like the recommended pattern going forward.

While intuitive nature of class component might be true you do not get access to all new react features though. Hooks, suspense, RSCs are all out of scope, including nextjs APIs like ‘useRouter’ etc.

[pastelsky]

Hello @pastelsky! I believe I can help with the migration to typescript but, would it make sense to migrate to functional components first? I think it would make the codebase more approachable.

@raulmarindev I don’t mind refactoring existing class components to functional components — though that shouldn’t be a pre-requisite for a typescript migration. The approachability of functional components vs class components is pretty subjective IMO — there have been times I’ve felt the other one was more intuitive. But FC’s do seem like the recommended pattern going forward.