Naming Convention

You should name your file and folder in kebab-case instead of snake_case, camelCase, or PascalCase.

Why?

Some file systems are case-insensitive (yes, I’m looking at you, Windows). That means ApiSpec == apispec == APISpec.

To avoid confusion, camelCase and PascalCase should be avoided. That leave us with snake_case or kebab-case.

I used to recommend snake_case, because double-clicking a snake_case name selects the whole name, while double-clicking a kebab-case name selects only one word.

That is a matter of editor settings, though. Most editors let you change what counts as a word separator, and renaming a file in the editor selects the whole name anyway.

The things around your files are not configurable, and they use kebab-case:

npm package names are almost always kebab-case, so a folder can share its name with the package it holds.
URLs use - to separate words, and search engines treat - as a word break and _ as a joiner. With file-based routing, the file name is the URL.
Custom element names must contain a -.
CLI commands and flags, git branch names, and CSS class names are kebab-case.

Using kebab-case for files and folders means one convention across all of them.

The exception is a language that imports a file by its name as an identifier. For example, Python cannot import customer-order.py. TypeScript has no such limitation.

You should name your file in nouns. i.e. customer-order.ts instead of create_customer-order.ts.

Why?

You might have heard of Single Responsibility Principle and think that you should have one function per file.

That is utterly wrong and not what SRP means.

SRP is about putting related code together where they have the same reason to change.

Naming (and thus organizing) the file with nouns will significantly make your file and folder a lot more stable.

Meaning there will be less import path changes.

You can use . to create sub-category on filenames.

Why

The name of the file should describe WHAT the file is about, in terms of its context or business value.

For example, customer-order.ts.

However, there are situations that you want to further organize the code into addition categories, so that it is easy to visualize as well as controlling the exposed API.

For example, you can do this:

customer-order.ts
customer-order.ctx.ts # context code for dependency injection
customer-order.internal.ts # code that you use internally, but exported for your tests.
customer-order.mock.ts # helper code for mocking the data during tests
customer-order.spec.ts # specification tests
customer-order.unit.ts # unit tests
customer-order.unit.electron.ts # unit tests only for electron

References

Another interesting take from Straw Hat’s ADRs.