unicorn/filename-case Style
What it does
Enforces a consistent case style for filenames to improve project organization and maintainability. By default, kebab-case
is enforced, but other styles can be configured.
Why is this bad?
Inconsistent file naming conventions make it harder to locate files, navigate projects, and enforce consistency across a codebase. Standardizing naming conventions improves readability, reduces cognitive overhead, and aligns with best practices in large-scale development.
Examples
Examples of correct filenames for each case:
kebabCase
some-file-name.js
some-file-name.test.js
some-file-name.test-utils.js
camelCase
someFileName.js
someFileName.test.js
someFileName.testUtils.js
snakeCase
some_file_name.js
some_file_name.test.js
some_file_name.test_utils.js
pascalCase
SomeFileName.js
SomeFileName.Test.js
SomeFileName.TestUtils.js
Options
case
{ type: 'kebabCase' | 'camelCase' | 'snakeCase' | 'pascalCase' }
You can set the case
option like this:
"unicorn/filename-case": [
"error",
{
"case": "kebabCase"
}
]
cases
{ type: { [key in 'kebabCase' | 'camelCase' | 'snakeCase' | 'pascalCase']?: boolean } }
You can set the cases
option like this:
"unicorn/filename-case": [
"error",
{
"cases": {
"camelCase": true,
"pascalCase": true
}
}
]
ignore
{ type: string }
Specifies a regular expression pattern for filenames that should be ignored by this rule.
You can set the ignore
option like this:
"unicorn/filename-case": [
"error",
{
"ignore": "^foo.*$"
}
]
multipleFileExtensions
{ type: boolean, default: true }
Whether to treat additional, .
-separated parts of a filename as parts of the extension rather than parts of the filename.
How to use
To enable this rule in the CLI or using the config file, you can use:
oxlint --deny unicorn/filename-case
{
"rules": {
"unicorn/filename-case": "error"
}
}