I recently finished reading _Working in Public: The Making and Maintenance of Open Source Software_ by [Nadia Eghbal](https://nadiaeghbal.com/), thanks to a book club organized by [Chris Traganos](https://twitter.com/chris_trag) at [Stripe](https://press.stripe.com/). While I can't say this is a book I would have found my way to own my own, I found myself tearing through it far more quickly than I would have guessed. I'd fully recommend giving it a read - you can pick it up on [Amazon](https://smile.amazon.com/Working-Public-Making-Maintenance-Software/dp/0578675862).

Below is a pretty raw copy/paste of my notes on _Working in Public_, which I take in Roam Research as I read. If you'd like to discuss any of this with me, drop me a line on [twitter @irreverentmike](https://twitter.com/irreverentmike).

**Notes on _Working in Public_**

# Part 1

## Chapter 2: The Structure of an Open Source Project

- &#8203;
 <Highlight>
 Developers don't contribute to open source for lack of technical ability,
 but rather due to fear of committing a faux pas
 </Highlight>
 - There's a huge hurdle to get over here, particularly for new contributors. Even
 sending a very small PR or opening an issue has a mental tax associated with it
 that can prevent progress, community from being built
- &#8203;

 <Highlight>
 The process of getting a change approved depends, among other things, on the
 **complexity** of the change (and the complexity of the project), as well as
 one's **reputation** among those with the ability to approve the change.
 </Highlight>

 - Reputation is a tricky currency, particularly when some folks build clout by
 being funny / sarcastic to gain viral notoriety. This doesn't necessarily equate
 to value to the community or trustworthiness, but often can be parlayed into exactly
 that.

- &#8203;

 <Highlight>
 If a project's contributor base is growing rapidly, and there is enough work
 to hand off, maintainers may start to distribute work more widely. In a
 **distributed** state, maintainers actively recruit more contributors to
 pitch in, with the goal of retaining them in the project.
 </Highlight>

 - At some point, the success of a project causes a requirement for a shift in operations
 - from building the thing to **supporting** it, and recruiting community members
 to help get things done on either end of that. Teams' ability to make that pivot
 is critical to success.

- &#8203;

 <Highlight>Healthy open source (re: node.js contribution policy)</Highlight>

 - Design a contribution policy and code of conduct which entices contributors **and** retains them. Based on my experience, this is the magic in getting something over the hump from being fledgling to more broadly successful.

## Chapter 3: Roles, incentives, and relationships

- Open source developers were frequently characterized as "hobby" devlopers
 - Hm! TIL.
- A theory of the commons
 - In the last half of the 1900s, economist Elinor Ostrom came up with an 8-part theory to what makes up a successful "Commons", or resource that is owned, used, and managed by a community. These rules outline the basic tenets of what makes a successful commons, and apply directly to successful OSS in many ways.
 - Making sure members are biased toward **working together** is a key to success. This may mean distributing knowledge and capability so that everyone has value and meaning, and no one person can hold up the process. Obviously encouraging collaboration is a valuable outcome here, too - so empowering folks to use each other as a resource is extremely helpful.
- <Highlight>
 Intrinsic motivation makes it easier for people to self-organize to achieve
 the same outcome.
 </Highlight>

- The newcomer effect
 - <Highlight>
 "Because newcomers have not yet developed commitment to the group and have
 not yet learned how the group operates, it is rational for established
 group members to distrust them"
 </Highlight>
 - This happens all the time in OSS - many projects have core maintainers who
 do all the work, and a significant amount of gatekeeping by way of bluntly shutting
 down PRs or issues when they're disinterested in them. It's fair to say that
 for the contributors getting shut down, a steady and consistent participation
 in the project will help them get notice, but it can feel like an unfair hurdle,
 too. What might be a more equitable solution to this? Not empowering code owners
 as much? Adding an objective, third party moderator to make some decisions?
- All Contributors
 - https://allcontributors.org/
 - Recognize All Contributors Including those that don't push code
- On Contributors...
 - Again, I'm reminded of the madness of Hacktoberfest 2020 - lots of garbage contributions from people just trying to get a free t-shirt does not make for good OSS, good community, or good contributions.
 - &#8203;<Highlight>Bus Factor</Highlight> is the number of contributors in a project
 who would need to be hit by a bus for it to be in jeopardy. lol

# Part 2: How People Maintain

## Chapter 4: The Work Required by Software

- Software, once written is never really finished. Chasing the feeling of a "finished" app/program/site is something that took me FOREVER to get over. I never felt like I had done anything, because nothing ever got to the finish line. It turns out that the finish line doesn't exist, and a decade+ of building "incomplete" things was the catalyst that I needed to figure that out. As such, <Highlight>greenfield</Highlight> projects are "coveted" because they're a blank canvas, enabling us to chase that feeling of a fresh _starting line_ to point us to a goal that is always just past the horizon. It's a feeling of hope - and thankfully a beneficial one, as rebuilding software from scratch is often inherently beneficial. Neat.
- <Highlight>Free as in speech, not as in beer</Highlight> vs <Highlight>
 free as in puppy
 </Highlight> is a brilliant analogy
- <Highlight>
 By focusing too much on iterating upon their incumbent product, companies
 risk missing major opportunities for so-called "disruptive innovation,"
 which eventually replaces existing products. - Clayton Christensen in Book:
 The Innovator's Dilemma
 </Highlight>

- The anecdote about Sophie Alpert being offered $600 to **open a PR on someone's project** because it would draw positive attention is mind-blowing.
 - "Is this what it feels like to be an influencer?" - Sophie
- <Highlight>
 We can think of a creator's reputation as a "battery," or store of value,
 for attention. More followers mean more attention in the bank, but when
 people follow a creator they do so because they expect to receive more
 content. If creators don't produce anything new, their followers will
 eventually get bored and leave. Reputation, like software, requires
 maintenance over time.
 </Highlight>

## Chapter 5: Managing the Costs of Production

- Absolutely mind-blowing that at one point, cryptographic code was treated the same as munitions by the US government. Early developers of OpenSSL <Highlight>had to become licensed arms dealers to be able to write and "export" (i.e., distribute) their code.</Highlight>
 - This is an implicit declaration that certain types of technical solutions can be weaponized, and perhaps just as importantly that sometime in the past, some of our legislators had a reasonable understanding of this. In the US, at least, it's apparent that this is no longer the case. Don't believe me? Pull up a congressional hearing with Tim Cook, Zuckerberg, etc
 - Relatedly, it is asymptotically difficult for lawmakers to keep up with the changing pace of technology. There's a decent argument to be made for a citizen-run, or commons-run governing body for technical regulation, rather that trusting some crusty old white men from flyover states whose pre-government professional lives weren't the least bit technical.
- <Highlight>
 When software is in static state, **what if there is no free-rider
 problem?** When code is non-rivalrous, it only has first-copy costs, which
 the creator is intrinsically motivated to provide -- so the problem doesn't
 seem to lie in how many people **consume** it. For this reason, I'm
 skeptical of attempts to charge for access to information, whether it's
 newspaper articles or open source software.
 </Highlight>

- This hints at one of the most fascinating things about content creators online. Virtually all of the really, truly successful creators are driven by an enjoyment of creating and sharing -- and might not typically start creating as a business. Often times it takes hundreds of youtube videos, or dozens of podcast episodes, blog posts, etc to get any kind of sizeable following. It's those with the fortitude and perseverance to continue without an audience that find success. Perhaps the audience is their reward, or perhaps the audience is a natural byproduct of the law of large numbers: create enough of something, and put it out into the world, and **some size** of audience will find you.
- <Highlight>
 At a high level, it's also possible that throwing away projects and starting
 fresh is the most cos-effective approach: rebuilding the whole system, piece
 by piece.
 </Highlight>

- There are many companies that operate like this - occasionally dropping an existing product for a **completely new** rewrite. This has been done with projects as small as weather apps and as large as Windows and MacOS, and is often a good decision. It strikes me that this is often only possible due to a luxury of funding, time, and resources. Imagine telling a scrappy startup that their best bet is to ditch their entire source library, and start anew. It wouldn't work! Many fledgling companies fall apart because of early and inflexible assumptions made, or technical debt built up to save time. The luckiest of them find success despite this debt, and carry on to be successful. I'd imagine this success often brings about an effort to rebuild the plane while it's flying, in a modern Ship of Theseus paradox.
- Automation! This section rang true with me to the core. When building [smpl](https://www.crunchbase.com/organization/smpl-llc), our biggest superpower was automation. It made our engineering team of 2 feel much larger than it was, and helped us to execute successfully and dependably. To this day I think that process automation is the closest thing I have to a superpower.
- It's interesting that a book about OSS has me thinking about work, content, and contributions outside of software so often. So much of what's discussed here has interesting implications politically, socially, and in content creation of any sort for public consumption (art, blogs, youtube, instagram, etc)
- I didn't know about [dear-github](https://github.com/dear-github/dear-github) or its relatives [dear-github2](https://github.com/drop-ice/dear-github-2.0) and [isaacs/github](https://github.com/isaacs/github). It'll be interesting to give these a read. As of this writing, `dear-github2` has had activity as recently as 2 weeks ago

### The role of Money in OSS

- Companies pay for access, attention, and feature proposals. This can often have adverse effects: companies are essentially skipping the line to pay for attention, and as a result aren't vetted by the same processes as other OSS Contributors (particularly those who request fixes and features). This can be a governance nightmare, and can cause mistrust in a project if done incorrectly.
- Advertising in OSS projects has real untapped potential, but often gets shot down. There was a product called Code Fund by Eric Berry which aimed to put ads into the readmes of OSS repos on github. It rose to $24k/mo revenue in 4 months before GitHub shut it down as a violation of their ToS.
- Trivago appears as a sponsor on Webpack, and this has helped them to recruit JavaScript developers, who see them as a good company to work for as a result of their support.
- An interesting difference in funding projects comes by way of GitHub's sponsors feature (and other services like Pateron), whose goals are more oriented towards having individuals back a **contributor** (rather than a project) on a monthly basis. The subscription is seen as a vote of confidence in the person, rather than slippery backing for a single project.

Book notes: Working In Public

## Earlier today, we had a problem at [Gymnasium](https://thegymnasium.com).

We released a [new 5 minute tutorial on Making Headings and Lists more Accessible](https://thegymnasium.com/courses/take5/making-headings-and-lists-more-accessible) - which is great news! If you build things for the web, and you've got 5 minutes to spare in your day (you do), you should give it a look.

After the course was made public, our marketing wizard did her magic and started posting to our various social media pages: [Facebook](https://www.facebook.com/aquentgymnasium), [Twitter](https://twitter.com/AquentGymnasium), and [LinkedIn](https://www.linkedin.com/school/gymnasium/).

It was immediately apparent that something was off. During our course release process, we missed the fact that Open Graph metadata for that course page wasn't correctly included. Unfortunately, that meant that _none_ of our posts on social media had the beautiful image previews that we'd expect to see (and by extension would likely see far less engagement).

<Aside>
 Open Graph metadata tells other services what kind of information is
 shown when a URL loads, so that they can create a preview of the URL that
 makes sense. Read more at{' '}
 <a href="https://ogp.me" target="_blank" rel="noopener noreferrer">
 ogp.me
 </a>
 .
</Aside>

Fast forward a short while, and we updated our CMS with the necessary metadata for Open Graph Shares to work correctly. Newly shared links in our team Slack now looked great!

<Image
 publicId="posts/open-graph-cache-reset/slack-after"
 alt="screenshot of a post in slack"
 caption="Screenshot from slack after the fix - our new course was shared with the correct image"
/>
.

## Social networks cache link previews

Rather than redownload the preview image and metadata for a given link every time it's shared, your entire open graph preview is often cached. Depending on the site, that cache may be cleared regularly throughout the day.

Because we had _already_ posted links to our courses, every site we had shared to had cached our shared links with the bare defaults. The result was relatively plain, and not relevant to the content on the page - something like:

`Free online courses on design and web development | Gymnasium`

With Gymnasium's logo beside it. Just defaults! Not a great look.

Because we were working on a concerted marketing push to announce our new courses, these extremely plain previews were bad news. We've seen from experience that having an attractive (and differentiated) share image helps gain traction during the initial publicity of new content.

## _You_ can trigger a cache reset on each of these sites!

After some brief research, we found that there are tools to reset the cache on each of the major social networking sites. They're each extremely easy to use - paste your URL in a box, click a button, and reset the cache if necessary. Here's the ones we found to be useful:

### Use these links

| Site | Cache reset tool link |
| :------- | :------------------------------------------------------------------------------------------- |
| Facebook | [https://developers.facebook.com/tools/debug/](https://developers.facebook.com/tools/debug/) |
| LinkedIn | [https://www.linkedin.com/post-inspector/](https://www.linkedin.com/post-inspector/) |
| Twitter | [https://cards-dev.twitter.com/validator](https://cards-dev.twitter.com/validator) |

That's all there is to it! Hit reset, re-share your link, and you should see your latest Open Graph preview shared. Phew! 😅

How to reset your Open Graph embed on LinkedIn, Twitter, and Facebook

Put simply, [gitignore.io](https://gitignore.io) is a tool that is so profoundly helpful that I've _forgotten what life was like without it._

Its purpose is simple: for any project you're working on, it'll generate a valid [`.gitignore`](https://docs.github.com/en/rest/reference/gitignore) file for you. All you need to do is use the autocomplete box provided to describe the type of project you're working on:

<Image
 publicId="gitignore-fill-in-the-blanks"
 alt="Screenshot of the web interface for gitignore"
 border="2px solid #888"
 borderRadius="1rem"
/>

<Aside type="note">
 A .gitignore file is used to tell git to exclude files from
 being added to a given repo. Each line of the file represents a filename,
 directory, or pattern. When git looks for changes in your working directory,
 it will automatically ignore any file that matches an entry in your .gitignore
 file.
</Aside>

From there, you'll hit the `Create` button, which will bring you to a page that displays nothing but the raw text which you'll need to add to your project's `.gitignore`. If you selected just `react`, for example this is what you'd see on the next page:

```
 # Created by https://www.toptal.com/developers/gitignore/api/react
 # Edit at https://www.toptal.com/developers/gitignore?templates=react

 ### react ###
 .DS_*
 *.log
 logs
 **/*.backup.*
 **/*.back.*

 node_modules
 bower_components

 *.sublime*

 psd
 thumb
 sketch

 # End of https://www.toptal.com/developers/gitignore/api/react
```

That's all there is to it, too! I use it on the vast majority of projects I work on, new and old, and as far as I can tell, it hasn't let me down in any meaningful way.

## It's Open Source!

One of the reasons I like this tool so much is that it gets better the more people use it. Is it missing support for a project type that you work with? Go ahead and submit a [Pull Request](https://github.com/toptal/gitignore.io), and it may be integrated into the product one day. Or, if you're not quite comfortable with a full-on PR, you can start the discussion in an issue on the repo. Maybe something isn't working like you'd expect -- and it's worth pitching in your two cents in the discussion on an open issue. _All of that_ is contributing to Open Source -- don't forget!

As I understand it, it was created by [@joeblau](https://twitter.com/joeblau), and quickly gained momentum with developers. As I write this post, there are [**135** contributors](https://github.com/toptal/gitignore.io/graphs/contributors) on the project.

[Gitignore.io](https://gitignore.io) is a great example of a successful Open Source tool born out of the desire for an improved developer workflow. It currently appears to be operated by [TopTal](https://www.toptal.com/), a company that helps freelancers find work.

<Aside type="info">
 
 (note for transparency: I have no connection to TopTal, and this is not a
 sponsored post. I <strike>do</strike> (update: 11/2020) used to{' '}
 work for{' '}
 <a
 href="https://aquent.com?utm_campaign=mikebifulco&utm_source=mikebifulco.com&utm_content=gitignore-io-is-great"
 target="_blank"
 rel="noopener noreferrer"
 >
 Aquent
 </a>
 , which is a creative staffing agency. If you're looking for work, give <strike>
 us
 </strike> them a look!).
 
</Aside>

## There's a CLI

If you prefer it, there's a [CLI](https://docs.gitignore.io/install/command-line) which will help you generate gitignore files, powered by this same project. I can't say I've used it, but I know some of you will want to give it a go, so it's worth mentioning

## There's other options, too

If you don't find gitignore.io particularly appealing, there's always other ways to cretae your `.gitignore` file. You can write it by hand, or grab one from another project you work on. [GitHub also maintains a repo](https://github.com/github/gitignore) of popular gitignore files, which seems to be updated quite frequently as well.

### Was this helpful?

If you found this useful, I'd love it if you subscribed to my mailing list. Details are below!

gitignore.io is great

_Note: I updated some names and links in this post. Dev.to's product became
**Forem** when it went open source_



So, like all good things, the idea for this post comes from a tweet:

<Tweet tweetLink="irreverentmike/status/1141169316273897536" align="center" />

This is something I've been ruminating on for a bit. I've even tried to build it - a few times! I keep starting in on the work and getting lost in the millions of directions I could take it.

Here's what I'd like: When I publish a new post to [my gatsby site](https://mikebifulco.com) (you're on it now!), I'd like for that post to appear on [dev.to](https://dev.to) automatically.

## It should:

- recreate my post verbatim, from its original markdown source
- use the `canonical_url` frontmatter field to make sure I retain SEO goodness on my post
- happen without my intervention
- be agnostic of where my posts are coming from. At the time of writing this article, I use [takeshape.io](https://www.takeshape.io) as a headless CMS for my site, so my individual posts aren't in source control
- only take posts from my `master` branch, since I use feature branches for draft posts from time to time
- use the [dev.to API](https://developers.forem.com/api) (update: now called the _Forem API_), of course

## Nice to have:

- maybe posts should be set to `published: false` at first, so I can preview/review/update them as needed for dev.to?

## Possible approaches for this:

1. Tap into GitHub's webhooks somehow, and fire off a post here
1. Come from a job kicked off after CI, maybe? I use CircleCI, but would like this feature to be fairly implementation agnostic.
1. Use a [GitHub App](https://developer.github.com/v3/apps/)?
1. ...or a [GitHub Action](https://github.com/mbifulco/thepraticaldev-crosspost-action)?
1. Perhaps just a lamba function deployed to AWS or [Netlify Functions](https://functions.netlify.com/).

So - here's where I ask for your help. Surely there's a simple approach here I haven't thought of, or maybe it's a matter of collecting a few scenarios and building something based on 80/20.

What else am I missing here? I'd love your help. What use cases would you have for a cross-poster from your gatsby site? How would you implement it? How can we help each other?

Do you have your own Gatsby site? Let's brainstorm a dev.to cross-poster

**Update (2021)** Dependabot has been Acquired by GitHub, and many of the links from this post stopped working once they took down the original site (dependabot dot com). I've updated URLs here to point to more relevant links within GitHub's docs.

[Dependabot](https://github.com/dependabot) is an automation service that will automatically create PRs to keep your projects' dependencies up to date, and it is fucking wonderful.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/dependabot-settings"
 alt="Screenshot of the settings interface for a project on the former Dependabot.com"
 caption="Setup for Dependabot is flexible, quick, and straightforward."
/>

In just a few, sweet, wonderful minutes, you can install and configure it to automatically keep an eye on your project dependencies, and set a daily or weekly schedule to submit updates and changes. Automation at its finest - dependabot is like having a super mindful teammate who keeps an eye on npm (or pip or rubygems or one of [many other languages](https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates#supported-repositories-and-ecosystems)) - you'll automatically get great, well-formed PRs for each dependency version bump, which you can test locally, or have sent up to your CI toolchain of choice.

After you run through the setup process, dependabot will monitor your repo and submit PRs to update individual dependencies on a daily or weekly rhythm (your choice!). If the PR contains an important security update, it will be assigned a label of Security, too.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/dependabot-pr"
 alt="An example PR from dependabot"
 caption="Automatically created PRs are simple and to the point."
/>

Honestly, for me, it's like adding a member to my team. I love automation, and I love making my life simpler. Until now, for all of my projects, myself or another teammate would regularly run through all the dependencies in a given repo, and manually update them one at a time, testing and pushing them to GitHub to be run through CI and then eventually merged by the team. The honest truth is that this process can take quite a while, and can be forgotten, and isn't mindful of important security updates at all. That's all over now.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/merge"
 alt="An example PR from dependabot"
 caption="Dependabot will merge this PR once CI is done, thanks to the @dependabot merge command"
/>

## What else?

There are a _ton_ of other features available to you the moment you install dependabot. It responds to a wide variety of commands by way of GitHub comment. In the screenshot above, I've approved a PR and asked dependabot to merge it as soon as CI has passed. Now I don't have to babysit the repo in order to merge updates! Sweet!

If your repo contains multiple languages, Dependabot can handle that. If you've got a complex monorepo with multiple files representing your dependencies (for example, a node project set up with Lerna), dependabot can monitor each dependency file individually, with different rules for each.

<Image
 publicId="posts/i-have-to-tell-you-about-dependabot/github"
 alt="Dependabot's announcement that they were acquired by GitHub"
 caption="Dependabot was acquired by GitHub"
/>

This was the final kicker for me. Dependabot was [just acquired by GitHub](https://github.blog/2019-07-25-one-million-dependabot-pull-requests-merged/), and is now available completely free for use. That's incredible! There's no reason for you not to give it a shot. Go check it out now, post haste!

Go install [Dependabot](https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates)!

_Note: the cover photo for this article comes from one of my favorite photographers, [Alex Knight](https://twitter.com/agkdesign), and was made available un [Unsplash](https://unsplash.com/search/photos/robot?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText). Thank you Alex for your work!_

I have to tell you about Dependabot 🤖

## I really don't like my laptop.

I've been using a 2017 Macbook Pro for the past couple years.  As I'm sure you've heard, it is a fiercely disappointing device largely due to its courageous lack of ports, flawed keyboard design, and astonishing sticker price.  My personal machine is a 13" version, with 16GB of memory, _no_ touchbar, and a 256GB SSD. When I bought it, upgrading to 16GB of memory seemed far more important splurging on processor speed or disk space.  That's probably still true - but I've found myself endlessly frustrated by the tiny capacity of the SSD in my day to day work.

Roughly once every 6 weeks, my machine grinds to a halt as I run out of disk space, so I have to suffer through all the usual suspects for clearing up some room:

- empty the trash
- delete unused applications
- make sure all my photos are moved to my NAS, cloud storage, and offsite archives
- remove old virtualbox VM images

## A new kind of purge

Last week, however, I came across a surprising new way to free up some disk space: clearing out `node_modules` directories.

Curiosity hit me, and I searched my mac for folders named `node_modules`. This is what I found:

- My machine has `7,731` _total_  `node_modules` folders.  Wow!
- Under `~/src/**`, where I keep all of my dev projects, I had a grand total of 7,719 `node_modules`
- These folders contain _hundreds of thousands of files_ (which should be no surprise), and took up nearly **10GB** of disk space!

## Turtles all the way down 🐢🐢🐢

That last number was a bit of a revelation to me at first.  If you're unfamiliar, `node_modules` contains a copy of each of the [npm packages](https://www.npmjs.com) which you add to your project (with `npm install` or `yarn add`, etc) on projects which use node.  Each of them are pinned to a specific version, which is typically specified in `package.json`.

Somewhat logically, each of the dependencies in your project's `node_modules` directory may also have a `node_modules` directory, containing their dependencies, each pinned to a specific version (again, defined in the `package.json` file of that dependency).

This is where file and disk space bloat happen - the libraries you add to your project may each contain dozens of dependencies, each of which have dozens more, etc etc, all the way down to super basic node and C libraries which make up the fundamental building blocks of node.

(Mind you - This is oversimplifying things a bit - depending on how you set up `npm` or `yarn` , there is _some_ optimization done here. If one version of a given npm module is required more than once by your dependency tree, it may only appear once.)

## The fix

Actually, this was pretty easy to fix.  I did a search for all of the `node_modules` folders under `~/src/**`, and deleted all of them, right from finder (sorry, terminal apologists).  I then emptied the trash on my mac, and I was 10GB richer.

<Image
 publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/disk-space"
 alt="Screenshot of MacOS folder info for a node_modules search"
 caption="10 GB of space, just for node_modules!"
/>

## What did it break?

It's been a week since I've done this. So far the only inkling of a downside is that when I revisit projects I'm actively working on, I need to run `yarn install` to recreate the `node_modules` directory there. I switch between a good handful of projects, and I'm back to a fair few directories, but at least these are just the ones I'm currently using. I'm good with that.

<Image
 publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/terminal"
 alt="Terminal search for directories called node_modules"
 caption="A week later, I'm back up to 1209 node\_modules directories"
/>

## Can we do better?

There is an alternative to `npm` and `yarn` called [`pnpm`](https://pnpm.io/), which claims to be a "Fast, disk space efficient package manager".  Its primary feature looks promising:

<Image
 publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/pnpm"
 alt="pnpm's value prop - one version of each package saved to disk"
 caption="One version of each module sounds great"
/>

I haven't tried it yet, but will certainly be giving it a shot.

## Epilogue 

I think it's fair to say that this is a problem that the folks at npm and Facebook (who maintain yarn) are also looking closely at. My guess is that some healthy competition will improve this disk space nightmare... hopefully before I'm forced to buy a laptop with 1TB of storage. 🥳

---

### More reading

I'm certainly not the first one to write about this.  Some more great reading for you to check out, if you're interested:

- [The node_modules problem](https://dev.to/leoat12/the-nodemodules-problem-29dc)
- [What Happened When I Peeked Into My Node_Modules Directory](https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558) (this is the infamous tongue-in-cheek Guy Fieri article)
- [What’s really wrong with node_modules and why this is your fault](https://hackernoon.com/whats-really-wrong-with-node-modules-and-why-this-is-your-fault-8ac9fa893823?gi=1ff87c0f83ba)

#tools: 6 posts tagged