[chore]: use `unicorn/filename-case` eslint rule about flat

[LitoMore]

We could allow kebab-case and PascalCase both currently.

For markdown files, I think we don't need too much rules for restricting its name. Because we need to append some language tags (zhCN, zhTW) to our markdown files.

"unicorn/filename-case": [
	"error",
	{
		"cases": {
			"kebabCase": true,
			"pascalCase": true,
			"ignore": [
				/.*\.md$/,
				/.*\.(yml|yaml)$/,
			],
		}
	}
]

[BlackHole1]

That feels down to the fact that this rule may not apply to our situation.
How about we redevelop it on top of it?

[BlackHole1]

Or we write a script to do this. Because the main rule of eslint is the code specification, not the filename specification. Its an AST we will not be using.

How do you feel?
cc: @netless-io/developers

[Cyberhan123]

That feels down to the fact that this rule may not apply to our situation. How about we redevelop it on top of it?

yes, you are right. other issue sindresorhus/eslint-plugin-unicorn#1577 .There seem to be other special problems

[LitoMore]

That's what I want to mention. We are putting ourselves into a complicated situation: create another tool.

If we only use kebab-case then we have nothing to worry about.

For eslint-plugin-unicorn, if some rules will occur with lots of file changes and are hard to fix then let us disable them or mark them as warnings.

My main point is to make our project rules simple and easy to maintain.

Any thoughts?

[Cyberhan123]

That's what I want to mention. We are putting ourselves into a complicated situation: create another tool.

If we only use kebab-case then we have nothing to worry about.

For eslint-plugin-unicorn, if some rules will occur with lots of file changes and are hard to fix then let us disable them or mark them as warnings.

My main point is to make our project rules simple and easy to maintain.

Any thoughts?

Do not worry, just write an git hook . that's enough

[LitoMore]

Just write a git hook. that's enough.

Let's go for it.