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.

[lit26]

Hi @pastelsky 👋 I'd be happy to contribute to bundlephobia. I have implemented the typescript migration for the frontend pages. Please check this PR: #743. Thanks.

[Scott-Fischer]

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

@pastelsky What about something like vanilla-extract? I'm personally really interested in their approach since it brings the type safety and scoping provided by CSS in JS but without the associated runtime overhead.

[artmsilva]

Hi, @pastelsky! I'd be happy to contribute or co-maintain. I'm maintaining an open source design system https://build.washingtonpost.com

[pastelsky]

@Scott-Fischer @artmsilva Do you mind creating another issue so that we discuss this in detail?

I'm not a big fan of CSS in JS libs with a custom syntax (e.g. object styles). It hurts portability and debugging. CSS-in-JS libs are a dime a dozen these days as well so would want to ideally stick with something that's standard CSS syntax (either string templating or something like CSS-in-JS) as its longer lasting.

Moreover, CSS is already typed (if you write them in CSS files with lint).

Happy to be convinced otherwise though.

[hspacheco]

Hello @pastelsky What is the main reason for the change from SCSS ? I'm wondering if it wouldn't be easier to refactor some classes and use them as module.scss, but I'm not sure about the main reason

[amirsalio]

פנח

[upteran]

Hi @pastelsky, firstly, thank you for your work. Are hands needed yet ? I checked PRs and tasks that you describe in the title, if I understand right, some of them are finished or out of date and needed to update. If work on the project continues I will be glad to help

But firstly, in my opinion, need to refresh all done tasks and update the scope of work, to make tasks more clear for contributors.

After that maybe create discussions or issues for each of the global tasks and discuss how they will be implemented, code styles, way of implementation, and so on. For example, can describe iterations and scopes of TS migration in a way to a few developers do not conflict with each other (same folders, place of types, etc.) And it will help to avoid situations when the view of maintainers (yours or maybe someone else) diverge with refactoring way.

Maybe need help with some organizational work, like creating PR/issues/issue templates or updating old ones.

Say if you have time and need help now because I understand that it is a huge work and need a lot of time

[sandstrom]

@pastelsky A small suggestion to help monetize this project.

Write a small CLI tool that will:

1. Check the diff of a PR for any added/removed/updated packages in package.json.
2. Call a private API on the Bundlephobia server, retrieving data for each version/package.
3. Show a text summary / ascii table with the size differences in percent, and a link to each package on Bundlephobia.
4. Add a simple login with a free tier of say 100 requests per month, and then paid in increments of 1000 lookups. Use stripe for billing. Motivate it by explaining that servers and maintaining the project costs money.
5. Put some information on the website, encouraging companies to run this CLI tool in their CI workflow, to post information to developers (thereby encouraging them to not add packages that have a high cost). Add a text guide explaining how to run it in Github actions (don't spend time writing a dedicated Github action, just give some example YAML of what an action/workflow would look like).
6. Bonus step (for later): write a VS code plugin that uses the same private API, and shows inline hints about size when writing import … from ….

Website would still be free, and project open-source.