by Josh Branchaud on March 26, 2019

While building a large React SPA, we reached a point where we needed to cut down the bundle size a bit. We identified some candidate dependencies -- packages that were being used sparingly but had a large footprint on the bundle. We then found some alternatives to those packages with a fraction of the bundle size. We just needed to be sure that these packages could do what we needed them to do. This is where CodeSandbox comes in.

We decided that we wanted to try to replace moment.js with day.js. Before making the switch, we wanted to be sure that day.js could do the things we needed it to do.

So, we spun up a fresh, vanilla Javascript CodeSandbox.

Under the Dependencies tab in the File Editor section is a big, blue button -- Add Dependency. That button pops open a search modal that allows you to find packages from the npm registry. Start typing day.js and it will quickly show up as one of the results. Click on it and it will be added as a dependency of the project.

We can now give day.js a test run in this isolated environment. We can compare what we are seeing in the docs with what we are able to get working in this sandbox environment. We were primarily using moment.js for formatting dates, so we went to work reproducing our formatting utilities with day.js.

This not only gave us confidence that day.js could do the things we needed it to do. It also gave us a tangible artifact that we could pass around to others on the team to get buy-in on the change. Once you save a CodeSandbox instance, you get a unique URL that you can pass around to anyone.

Now that we were satisfied with day.js and had buy-in from the rest of the team, we could set out to create a pull request that would make the switch.

CodeSandbox has become invaluable to many parts of my workflow. But I've especially come to depend on it for evaluating my dependencies.

Cover photo: Wolfgang Hasselmann