Rachelle Rathbone

Naming files on Mac or Windows vs Linux

How One Letter Can Make Your Build Fail in a Deployment

November 03, 2019

It's been a while since I've run into this issue but a recent deployment to Netlify brought back some painful memories.

Recently I added social media sharing buttons to my post pages. I ran gatsby build && gatsby serve, the build completed successfully and everything looked good locally. I pushed to my master branch and sat back waiting for a minute or two while Netlify did its thing. I refreshed my browser expecting to see the changes live on my site but they weren't there. I tried a hard refresh thinking maybe I was just seeing an old version of my site... no dice.

Pulling up my Netlify account I quickly discovered that the build had failed. Opening the logs, it didn't take me long to find the source of the issue.

The error momentarily threw me because I knew that path was correct *and* the build had passed on my machine. On closer inspection of my assets directory I discovered that the svg file was, in fact, all in lower case, meaning the path to that asset should have actually been: '../../content/assets/social-media-icons/linkedin.svg'. So why did the build pass on my Mac and not on Netlify? It's because of case sensitivity.

Windows and Mac are case insensitive which means I could've included something like 'LiNkeDiN.svg' in the path to the linkedin.svg asset and the build still would have passed because my machine simply doesn't care about case. However Netlify, which uses Linux under the covers for the build image, does care about case sensitivity. If you have one wrong character, just as I did, and you're working with anything that uses Linux, well, your shit just ain't going to work.

At the start of this post I mentioned this experience brought back painful memories. In 2018, when I was working at a startup, myself and another engineer I worked with, Ross Todd, named our React files in the standard ReactJS fashion: with PascalCase. Our boss called out the naming convention and asked us to switch to using camelCase to be more uniform with the backend apps and to prevent issues with case. Ironically, changing the file names is what created a whole world of hurt for me and Ross because guess what, Git cares about case as well. We already had all our files committed to source control and then we went ahead and changed all our javascript file names. Any time one of us pulled down the other's changes, we'd be greeted with files having randomly reverted back to their former PascalCase version and sometimes there would be 2 of each file, one PascalCase and one camelCase. It didn't how many times we changed the file names of what we did to resolve the issue and it was an ongoing battle to get builds to pass so we could do a deployment. Our solution in the end was to blow away the repo in Github and set it up again. Not ideal as we lost all our commit history but it prevented both of us from losing our minds.

Take care when naming files, friends. Pick a case, stick with it, and be mindful of those import paths.
© 2023, Rachelle Rathbone