File name case issue (avoid caps and CamelCase)

[SachaG]

I'm used to naming React components using CamelCase (MyComponent.js) but I just realized that although this works fine locally, it doesn't work with GitHub Pages routing.

I would suggest Gatsby just normalize every name to lowercase at build time, so a MyComponent.js page would become a mycomponent/index.html file instead of the current MyComponent/index.html.

[KyleAMathews]

Is there not use cases for having upper-case urls?

It seems like it'd be confusing to modify URLs like this e.g. what if someone wanted a handful of URLs to be uppercase or even if they had two urls with the same letters just with different casing.

I'd suggest just using the rewritePath api (not documented atm) https://github.com/KyleAMathews/blog/blob/7caa79d25b36e2204760df7ce993fd15543021f5/gatsby-node.js#L3 to change the case on your URLs.

[SachaG]

I feel like upper-case URLs are probably a bad idea anyway? I can't really think of a use case where you'd want to have both /foo and /Foo and have them point at different pages. In any case GitHub pages doesn't handle case-sensitive URLs.

[knpwrs]

As far as the node community is concerned, kebab-case is preferred for all file names. You'll see a lot of people, especially in the React community for some reason, who use CamelCase for filenames. This convention comes from the thinking of "this file is a class (or component)," whereas the former convention comes from the thinking of "this file is a module which happens to export a class (or component)."

The former is preferred for consistent imports:

import 'some-module/sub-module';
// vs
import 'some-module/SubModule';

Furthermore, consistently using kebab-case will avoid silly case issues across different systems.

[KyleAMathews]

Reducing the number of concepts that make up a framework is a useful design principle. Right now there's one rule — the JS filename becomes it's URL. If we make this change @SachaG there'd be two rules, (filename) => URL unless filename is capitalized. Since it's easy enough to programmatically add this extra rule I'd say let's just keep things as they are.

[SachaG]

Well I guess one way makes for a simpler codebase and a more complex experience, and the other way is the opposite. It's all about trade-offs… :)

[machineghost]

Since it's easy enough to programmatically add this extra rule I'd say let's just keep things as they are.

How does one easily remove case sensitivity from Gatsby URL processing?

To me having overlapping (but with different casings) URLs is an abomination, as is needlessly sending the user to a 404 page ... when a perfectly valid page (just with a different casing) is sitting there waiting for them. So how can I avoid both of those nightmare scenarios and still use Gatsby?

EDIT: Related Stack Overflow Question: https://stackoverflow.com/questions/62559366/gatsby-how-can-i-have-case-insensitive-dynamic-urls