Call for contributors and co-maintainers

[pastelsky]

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 ❤️

[ardalanamini]

Hi @pastelsky I made the pastelsky/package-build-stats#53 PR in regard to upgrading to webpack 5, which also adds support for multi-entry packages (with package.json exports field) as well as sub-path imports (package.json imports field) as a side effect of the upgrade, hope it helps 👍🏻

[megancooper]

I want to dive into opensource and would love to contribute 👋🏽

@pastelsky I'm interested in helping move the repo from SCSS. Would you be open to using tailwind instead of emotion? It has dark mode support, and the DX is great. I was hesitant at first, but it really makes the process of writing styles much more streamlined

[darasus]

Hi @pastelsky 👋 I'd be happy to contribute to bundlephobia. I built js.watch for fun using package-build-stats. Would like to have a chat with you and see if I can help in any way.

[pastelsky]

👋 @megancooper Thanks a lot for expressing interest — and sorry it took long for me to respond. I'd love for bundlephobia to be available in dark mode. I can't say I have a lot of experience in tailwind, and I'm sceptical about maintainability and readability in the long term. I think it'd also require use to rewrite all of our existing styles — which can be a large task.

Instead, I was thinking of something more lightweight — using CSS variables to replace all our color variables with tokens?
I'm also open to the idea of using a statically extracted CSS in JS solution (currently I use SCSS).

It would be great to take this further regardless of the specifics of implementation. What do you think?

[pastelsky]

@darasus love the 2D aesthetics of js.watch. I've noted down a few areas we need help with in my original post. But if there's anything else, feel free to drop into bundlephobia's discord channel.

[raulmarindev]

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.

Additionally, there seems to be an issue that can prevent some contributors to work in the project. #702 I created a PR to fix it #703

[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.

[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.

[raulmarindev]

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.

I agree. Additionally, FC+hooks has been the dominant React way for a few years already. If you think about the pool of potential contributors I believe it'll be easier to find those who are more comfortable working with FC because that's what they normally use.