
<YouTube youTubeId="V2izYekSSwY" />

From [Google I/O 2021](https://io.google/2021/): In this session, we (I) discuss marketing activities that help users discover and engage with what you’ve built on Google Assistant, as well as some updates to monetization features for Conversational Actions.


Driving a successful launch for Conversational Actions


<YouTube youTubeId="HX1bMuoZ6II" />

As a part of my work as a DevRel lead for Google Assistant, I did a guest segment on VOICE Talks in August of 2021, talking about why UX research for voice-first experiences is so crucial.


VOICE Talks August 2021: Trust the researchers for voice-first UX


<YouTube youTubeId="cw1wlHV4hGk" />

Tools like Eleventy, Hugo, Gatsby, Svelte, and others have given developers a superpower for quickly developing content-driven, easily manageable web properties. It's an exciting frontier for developers who are also content creators, but for non-technical creators, our favorite toolchains can feel like a labyrinth of indecipherable choices.

In this talk, we'll discuss our role in promoting the creator economy. We'll talk about the opportunity we have as developers in helping to democratize content creation for everyone, and the importance of creating a more robust, archival internet.

[Check out the slides](https://docs.google.com/presentation/d/1XFJ_nQfPnX0oPOUezOEwVKLZFtptTKemtGg41RJPisQ)


JAM Stack, SSGs, and their role in empowering the creator economy


<YouTube youTubeId="OaF_WhzNAKQ" />

From my work as a Developer Advocate on the Google Assistant team, this tutorial explains the difference between _shortcuts_ and _dynamic shortcuts_ for Android, and how to use Assistant to take advantage of this functionality.


Push dynamic shortcuts to Assistant


<YouTube youTubeId="lxviLXXvs3A" />

A brief, 2-minute Demo from [Google I/O 2021](https://io.google/2021/): learn how to create your first App Action for an Android app, which lets you connect your app's features to Google Assistant


How to create your first App Action


<YouTube youTubeId="z6l-V-EOGNY" />

A quick demo from [Google I/O 2021](https://io.google/2021/): we take a look at some user experience (UX) changes for card verification code (CVC) confirmation and new payment method entry for payments on smart screens.


New Transaction Features for Smart Displays


<Image
  publicId="external-references/fullstack-dev-article-aquent/cover"
  alt="Article screenshot: What the Heck is a Fullstack Developer? Aquent UK blog"
/>

An interview with my former employer (and parent company of [Gymnasium](https://www.thegymnasium.com/)), [Aquent](https://aquent.com) about my thoughts on what it means to be a Fullstack Developer.

Description from the article:

<Aside>
  To shed light onto what is for many a mysterious role—Full Stack Developer—we
  talked to our own Star of the Full Stack, Mike Bifulco. Currently the Director
  of Technology for Aquent Gymnasium, he was previously a User Experience Lead
  and Program Manager at Microsoft.
</Aside>

Full article is available to read on [Aquent UK's blog](https://aquent.co.uk/blog/what-the-heck-is-a-full-stack-developer).


What the Heck is a Fullstack Developer? Aquent UK


<Image
  publicId="external-references/proximity-acquires-smpl/cover"
  alt="A screenshot from a press release announcing proximity acquiring smpl"
/>

In early 2020, [smpl](https://smpl.io) was acquired by [Proximity](https://proximity.space). I was cofounder and CEO of smpl - we proudly helped independent coworking spaces manage their communities with automated billing, invoicing, and community management. It was a wild ride, and I couldn't have done it without my two amazing cofounders.

We were acquired by our biggest competitor, Proximity, who are continuing the dream by creating a network of amazing, independently owned coworking spaces around the world.

[Read the press release about the acquisition](https://www.proximity.space/news/proximity-acquires-smpl-software/) to find out more.

There is another (paywalled) article on [Business Insider](https://www.businessinsider.com/inside-a-coworking-software-deal-proximity-buys-smpl-2020-4) about the acquisition, too!

[More about smpl](https://www.crunchbase.com/organization/smpl-llc) on Crunchbase.

Tools we used to build smpl:

- [Firebase](https://firebase.google.com/)
- [Stripe](https://www.stripe.com)
- [React](https://reactjs.org)
- [Intercom](https://intercom.com)
- [LogRocket](https://logrocket.com)


Proximity Acquires SMPL Software


<Image
  publicId="external-references/matter-a-whole-thing/cover"
  alt="Cover slide: MATTER - a whole thing about design"
/>

From a talk I gave at my then-home-base [Hygge Coworking](https://wearehygge.com/) at a community event. The thesis: we're all designers, and you should give a damn about the things you put into the world.

Slides are [available on slideshare](https://www.slideshare.net/mbifulco1/matter-a-whole-thing-about-design).


Matter - a whole thing about design


<YouTube youTubeId="ukPI1zlxKqg" />

From my days working as Technical Director of [thegymnasium.com](https://thegymnasium.com): a 5-minute tutorial (lovingly referred to as a **Take 5**) showing how you can use GitHub pages to host your very own website.

The full tutorial (with additional reference material) is available **for free** on [The Gymnasium](https://thegymnasium.com/courses/take5/publishing-your-first-github-pages-website)

Gymnasium is a treasure - if you like this, get yourself a free account at [thegymnasium.com/register](https://thegymnasium.com/register), and start learning at your own pace today!


Publishing Your First GitHub Pages Website - Gymnasium Take 5


<Image
  publicId="external-references/the-perils-of-obedience/cover"
  alt="title slide: The Perils of Obedience, by Mike Bifulco"
/>

These are slides from a lightning talk I gave at a local conference in 2018.

I explain the Milgram Experiment, how absolutely terrifying it is, and how understanding Cognitive Psychology and Social Sciences can help us make the world a better place.

I also implore the audience to go register to vote. [turbovote.org](https://turbovote.org). Go do it!

Slides [available on Slideshare](https://www.slideshare.net/mbifulco1/the-perils-of-obedience) if you're interested in perusing.


Lightning Talk: The Perils of Obedience


<Image
  publicId="external-references/design-matters-zero-day/cover"
  alt="title slide: Design Matters, Hygge Zero day"
/>

These are slides from an empassioned talk I gave about design during a community event called Zero Day at [Hygge Coworking](https://wearehygge.com) in Charlotte, NC, USA.

The thesis: good design is important, and you should be paying attention to good-and-bad design in the world around you. Contributing to making the world better for everyone **is** everyone's job.

Slides [are available on SlideShare](https://www.slideshare.net/mbifulco1/design-matters-hygge-zero-day-93804671)


Design Matters, Hygge Zero day


<Image publicId="external-references/50-most-powerful-startups-in-charlotte/cover" />

I was cofounder and CEO of [smpl](https://smpl.io), a SaaS startup helping independent-scale coworking operators automate their business. We were featured in a 2017 Article by Axios Charlotte (then called **The Charlotte Agenda**) as one of the most powerful (lol) startups in town. Pretty cool!


50 Most Powerful startups in Charlotte


<Image
  publicId="external-references/edx-comprehensive-theming/cover"
  alt="Cover slide: Edx Comprehensive Theming tutorial, by Mike Bifulco"
/>

A talk I gave at Stanford University in 2016 on Comprehensive Theming for [Open EdX](https://open.edx.org).

Slides [are available on Slideshare](https://www.slideshare.net/mbifulco1/edx-comprehensive-tutorial)


Edx Comprehensive Theming Tutorial


<YouTube youTubeId="2VJmjmESvMo" />

(My talk starts at 5 minutes and 43 seconds into the video)

From [Open EdX Conf 2016](https://open.edx.org), this is a lightning talk I gave on our strategy for student support at [Gymnasium](https://thegymnasium.com), while I served as Technical Director there.


Open EdX, Slack, and Intercom


<Image
  publicId="external-references/30-under-30-2016/cover"
  alt="Photo of me being recognized as one of Charlotte's 30 under 30 in 2016"
/>

Not much on the web about this these days, but if you really want to go spelunking, here's a Wayback Machine link from late 2016 that's captured the gist of it. [Wayback Machine: Top 30 Under 30 Future Leaders of Charlotte, Elevate Lifestyle 2016](http://web.archive.org/web/20161115035530/http://elevatelifestyle.com/30-under-30-2016), and an [old facebook event](https://www.facebook.com/events/1088933411127102/).


Top 30 Under 30 Future Leaders of Charlotte - Elevate Lifestyle 2016


<Image publicId="external-references/your-app-is-ugly/cover" />

A rehash of a talk on the basics of design and aesthetics, covering color theory, swiss design, and some of the historical roots of modern design.

Authored with Andrew Miller, Jeremy Osborn, and Leah Cunningham

Slides [are available on SlideShare](https://www.slideshare.net/mbifulco1/your-app-is-ugly)


Your App is Ugly


<YouTube youTubeId="5DiJ_2Bz2hM" />

(My part starts at 13m47s, but you should watch the whole thing!)

This is a talk I gave during [Open Edx Conf 2016](https://open.edx.org) with my colleagues, comrades, and brothers in arms Andrew Miller and Jeremy Osborn, talking about how we built Gymnasium while actively experimenting with formulas for an effective MOOC.


Gymnasium - Building the plane while flying it


<Vimeo vimeoId="84388498" />

This is a talk I gave at [Blend Conf](http://2013.blendconf.com/speakers/mike-bifulco/) in Charlotte, NC USA in 2013, when I was working for [Microsoft](https://microsoft.com) as a UX Designer. If you're interested in learning how to design apps for a version of Windows that came out in 2012, this is your day!

Slides are [available on Slideshare](https://www.slideshare.net/mbifulco1/designing-windows-81-apps-from-the-ground-up)


Designing Windows 8.1 apps, from the ground up


[Dependabot](https://dependabot.com) 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 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://dependabot.com/#languages)) - 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://dependabot.com/blog/hello-github/), 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://dependabot.com/)!

_Note: the cover photo for this article comes from one of my favorite photographers, [Alex Knight](https://unsplash.com/@agkdesign?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText), 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!  Go support him on [Patreon](https://patreon.com/agk42), and give him a follow on [Twitter](https://twitter.com/agkdesign)._

I have to tell you about Dependabot 🤖



This is a follow-up to my [first post](https://mikebifulco.com/solve-all-your-problems-with-promise-allsettled) on the upcoming `Promise.allSettled()` function, coming soon to a node application near you. 

Earlier today I was greeted by a [Pull Request](https://github.com/mbifulco/blog/pull/14) on my first post from GitHub user `@j-f1`.  

  
<Image
  publicId="posts/promise-all-settled-pt-2-its-partly-settled/pr"
  alt="Screenshot of a github pull request on my last blog post"
  caption="PR on my last post, showing how to use Promise.allSettled() now!"
/>

It turns out there _is_ a handy way to add `Promise.allSettled()` to your apps _right now!_ 🎉.  It's fiendishly simple to use, too.

## **The core-js npm package**

That's right - [core-js](https://github.com/zloirock/core-js).  From their `README.md`, it is exactly what it sounds like:

<Aside>

  It is a polyfill of the JavaScript standard library, which supports:  
  - The latest ECMAScript standard.  
  - ECMAScript standard library proposals.  
  - Some WHATWG / W3C standards (cross-platform or closely related ECMAScript).  

  It is maximally modular: you can easily choose to load only the features you will be using.  
  It can be used without polluting the global namespace.  
  It is [tightly integrated with `babel`: this allows many optimizations of `core-js` import.](https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#Babel)

</Aside>

[Looking further down in the readme](https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#Babel), there's a list of supported features in the polyfill:

<Aside>

  [Promise.allSettled](https://github.com/tc39/proposal-promise-allSettled) stage 2 proposal

</Aside>

Well hot damn! That'll do it! 

## **How to use core-js**

As `@j-f1` indicated, in any project that uses `babel` as a transpiler, all you need to do is add core-js to your project, and include it at your app's entry point:

First, add the dependency to your project

```bash
    > yarn add core-js
```

Then, at your app's entry point (usually something like `index.js`, or `app.js` in the root of your project):

```js
  import 'core-js';
```

or, if you want to include _just_ the `Promise.allSettled()` polyfill, and nothing else, use:

```js
  import 'core-js/proposals/promise-all-settled';
```

That's it! 🍻

Promise.allSettled() Pt.2 - it's partly settled!


Note: this is a follow-up to my [first post](https://mike.biful.co/deconfusing-javascript-destructuring-syntax) on destructuring.  Import syntax uses destructuring pretty liberally, and it can be really confusing for folks who are new to using it. Give my other article a read first if this all seems confusing!

Let's talk about importing dependencies into your node projects.  As your work gets more complex, you will inevitably come across syntax like this:

```js
  import React, { useState, useEffect } from 'react';
  import { Link } from 'gatsby';
  import Button from '@material-ui/core/Button';
  import moment from 'moment';
  ​
  import { Layout } from '../components';
```

At first glance, it's pretty straightforward.  We're importing a handful of bits to use in a React component.  As you might imagine, though, I've selected these four lines of code because each one is unique.  In fact, during my journey as a blossoming Node/React developer, I've found ways to mess up _every single one_ of these.  

You're gonna mess this stuff up, too, and that's perfectly fine! For now, I'm here to help.

We're going to look through each one of these, in order of complexity, and I'll do my best to explain what the hell is going on, and the way I think about imports as I work.

## **Straightforward import syntax - the easiest case**

```js
  import moment from 'moment';
```

If you've worked in .Net languages, or Python, or Ruby, or one of many other languages under the sun, this should be second nature to you.  I'm calling it out here specifically because some of us may never have seen it before.

### **What's going on here?**

Well, it turns out it's pretty easy.  [moment](https://www.npmjs.com/package/moment) is a JavaScript library, which has been included in our node project's `package.json` file's `dependencies` or `devDependencies`.  If you're new to node and are unfamilar with `package.json`, read more about it [here](https://nodesource.com/blog/the-basics-of-package-json-in-node-js-and-npm/).

This line of code creates a reference to everything made available in the `moment` library, and puts it into what is effectively a variable that we can use to access it.  the `'moment'` bit (in quotes) is what tells the compiler which library to get.  The other one, `moment` (_not_ in quotes) is the variable.  So from here in, we can access moment just like any other variable in this file:

```js
  import moment from 'moment';
  console.log(
    moment().get('year')
  );
  // 2019
```

### **The un-obvious bit**

Behind the scenes, this is just taking everything that is made available by the `moment` library through `export default` [in its main file](https://github.com/moment/moment/blob/develop/src/moment.js#L95) , and stuffing it into a variable - and that variable can have _any valid name_ we want!  

It may be confusing, but you absolutely could do this, if the this name made more sense to you:

```js
  import ThatReallyUsefulDateLibrary from 'moment';
  console.log(
    ThatReallyUsefulDateLibrary().get('year')
  );
  // 2019
```

## **Importing a component from somewhere within a library** 

Next up - this slightly more complex beast:

```js
  import Button from '@material-ui/core/Button';
```

Here we're grabbing the `<Button />` component from the [@material-ui library](https://material-ui.com). Again, this is fairly straightforward - but it may be helpful to think of this in terms of the structure of the material-ui project.  Material-ui exports _loads_ of great stuff, and it's all organized into logical groupings.  Think of it a bit like this:

```js
  // material-ui exports
  const muiExports = {
    core: {
      Button: () => {}, // some component
      TextField: () => {} // another useful component
      // and loads more
    }
  }
```

With the import syntax for `Button` above, we're telling the compiler to give us a reference to the exported thing called `Button`, which is found in the `@material-ui` library under `/core/Button`.  The compiler essentially treats this like the JSON object in the snippet above.

Here's the thing - that _also_ means we can destructure it! 😁. This syntax would also work to import `Button`:

```js
  import { Button } from '@material-ui/core';
```

That also means we can import _multiple things_ from `/core` in a single line!

```js
  import { Button, TextField} from '@material-ui/core';
```

Cool, huh? I know this can be confusing, but try to stick with it.  It'll all start to make sense to you before long.  This brings us to our next example:

### **Importing a subset of a library by way of destructuring**

```js
  import { Link } from 'gatsby';
```

Boom! This should be easy by now.  One of the things that `Gatsby` makes available is their [`link`](https://www.gatsbyjs.org/docs/gatsby-link/) component.  We're importing _just that component_ to use here.

### **Renaming an import**

But what if we already have a component called `Link` in our project? Or, what if we're making a Legend of Zelda fan-site, and `Link` is already defined in a component or variable that we can't rename?  Well, it turns out renaming something in an import is as easy as renaming something in a destructured statement.   We can rename the same component from `gatsby` like this:

```js
  import { Link as GatsbyWebLink } from 'gatsby';
```

We can also rename _one or many destructured imports_ in a single statement:

```js
  import { 
    Link as GatsbyWebLink,
    graphql as graphqlQuery,
    useStaticQuery
  } from 'gatsby';
```

Piece of cake! 🍰

## **Relative imports**


One more quick thing - the compiler knows to look for something _you_ exported if you use a _relative path_ in your import location string:

```js
  import { Layout } from '../components';
```

Just like anywhere else, you can combine and rename things to your heart's content here:

```js
  import {
    Layout,
    Button as SuperButton
  } from '../components';
```

## **Putting it all together**


The best isn't alway last, but this is certainly the last example I've got to share today:

```js
  import React, { useState, useEffect } from 'react';
```

If you've been playing along at home, this should all be familiar now - we're grabbing the default export from `react`, which we've put into the variable `react`.  We also destructured `useState` and `useEffect` from _the same library_.  If you're asking yourself "Well couldn't we also access `useState` as a child of `React`"? The answer is - well, actually, yeah!

This is perfectly valid

```js
  const [loading, setLoading] = React.useState(false);
```

… but it's not as nice to type or to read as 

```js
  const [loading, setLoading] = useState(false);
```

They're both equally functional from an execution standpoint, but the latter is used by convention.

## **I think that's it.**

I think.  It turns out this was a really tricky post to write - there's a billion ways to import a file, and there's probably loads of cases I've missed here.  There are _definitely_ also performance and bundle size implications for some of the varieties of import syntaxes shown here.  While they're absolutely real constraints, and have real implications on your app's performance, I left that discussion for another day - purely for the sake of simplicity.

There's also the not-so-small matter that using [import](https://caniuse.com/#feat=imports) requires a transpiler like Babel or Webpack right now.  That's another super-complex universe that I'm not sure i'm equipped to explain in a single blog post.  This also means I've skipped showing how any of the above syntax works with `require()`.  There's frankly an exhausting amount to explain here - future improvements to EcmaScript and node will make it all better.

## **Say hi!**

As always, if I've gotten anything wrong here, I'd love to know about it! Drop me a line [@irreverentmike](https://twitter.com/irreverentmike).  I'd love to hear from you. 👋

Picking apart JavaScript import syntax


## 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://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.js.org/), 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)

#npm