Filenames with different UpperCamelCase are unsafe in case-insensitive filesystems

[joaojeronimo]

Using upper-camel-case for filenames, or any sort of case that involves different letter casing, is dangerous when your team includes developers committing code from case insensitive filesystems (mostly people with windows and NTFS, and OSX and case insensitive HFS+).

It's a problem specifically when a developer in a case insensitive filesystem renames a folder in a way that just changes the folder's case, and pushes it. Because github (and probably all git hosts) run on linux, you'll get an inconsistency there that you will not observe in an inconsistent file system.

For instance if you had Button/Button.jsx and Button/style.css, and you rename the button folder and file to button/button.jsx, in the remote git repository you would end up with two folders, button/button.jsx and Button/style.css. Nothing would be different in your local filesystem.

I understand if you strictly follow the conventions and never ever change a folder case you will be fine, but it's easy to overlook if someone does it.

[goatslacker]

Why would they be changed?

[joaojeronimo]

Refactor ? Mistakes ? It's good a style guide allows for those wouldn't you say ?

[joewood]

+1 on this.
Mostly recommend lower-case filenames. For JSX files I simply separate the casing with "-". e.g. reservation-card.jsx.

[goatslacker]

It's a good thought but at Airbnb we follow PascalCaseNaming practices. You're welcome to fork our guide though and add your own rules :)

[jesucarr]

The PascalCaseNaming practice is good for code, not so much for file systems. Not only to avoid errors in case insenstivie OSs but I also had troubles in the past with git picking up case changes. Lowercase would align better with npm, where it's a requirement for package names.

[ljharb]

npm however has no such requirement for file names. Case-insensitive OS's are unfortunately at a disadvantage in the ecosystem. Certainly, if you use one, you'll want to fork the guide and alter this recommendation. (git definitely can have issues when renames solely change case, but since this only happens when a filename was created incorrectly in the first place, it's not much of a concern)

[jesucarr]

I mean, if you publish to npm a library called "Airbnb Lib" that exports a class named AirbnbLib, you won't be able to name it AirbnbLib and import it as const AirbnbLib = require('AirbnbLib');. The name of the folder needs to be lowercase, so in that sense npm has filename requirements. For the internal folders you can name them as you want, but if a dev names incorrectly in the first place, for example airbnbLib, then to correct it you need to deal with the git issues.

[ljharb]

Sure. However, this standard (name filenames to match the casing of the default export) doesn't apply to packages - see import $ from 'jquery', import React from 'react', import _ from 'underscore', import _ from 'lodash', etc.

The git issues only apply when renaming or creating a file - otherwise it should work just fine.

[madhurgarg71]

I literally faced this issue. One of my file name was "LiveUnassignedOrdersListItem.js". It was working on my local system (OSX), but when I tried to put the build on cloud server the build was failing. These are such bugs you can't debug easily.

[joaojeronimo]

if only @goatslacker would re-open the issue also take the opportunity to fix file case naming at airbnb... Would be great for the community as everyone looks up to this codestyle to see what's right and wrong.

[ljharb]

Our current file naming isn’t broken. Our linter config complains when you import files with the wrong casing, and this makes things work fine regardless of underlying case sensitivity.