Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[chore]: use unicorn/filename-case eslint rule #1080

Open
BlackHole1 opened this issue Nov 10, 2021 · 7 comments
Open

[chore]: use unicorn/filename-case eslint rule #1080

BlackHole1 opened this issue Nov 10, 2021 · 7 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@BlackHole1
Copy link
Collaborator

BlackHole1 commented Nov 10, 2021

Previously, we discussed the specification of file names (see: #714)

But this is all built on an ego-driven basis and we need to have a rule to help us check this.

Thanks to @LitoMore recommendation, we were made aware of the existence of unicorn/filename-case.

Rule Link: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/filename-case.md

The following rules, which I have just come up with, may not be perfect.

"unicorn/filename-case": [
	"error",
	{
		"cases": {
			"kebabCase": true,
			"ignore": [
				"^[A-Z].+\\.tsx$",
				"^README.*\\.md$",
				".*\\.yaml",
				".*\\.yml"
			],
		}
	}
]
@BlackHole1 BlackHole1 added enhancement New feature or request good first issue Good for newcomers labels Nov 10, 2021
@LitoMore
Copy link
Member

LitoMore commented Nov 10, 2021

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

BlackHole1 commented Nov 10, 2021

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
Copy link
Contributor

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
Copy link
Member

LitoMore commented Nov 10, 2021

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
Copy link
Contributor

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
Copy link
Member

LitoMore commented Nov 10, 2021

Just write a git hook. that's enough.

Let's go for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants