-
-
Notifications
You must be signed in to change notification settings - Fork 665
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
Rule proposal: slot-name-casing
#2580
Comments
Makes sense. It should have a single option that defines the style to use ( PR welcome to implement the rule! |
The vue docs ship around this discussion by only using single word slot names. So if anyone else has good arguments for or against using |
Thanks for checking! |
On the other hand camelCase might not work properly in in-dom templates |
That's true and it should be mentioned in the rule's documentation. Thanks for bringing that up! However, I think that it shouldn't dictate the rule's default style because…
|
How about having 3 options: |
That's a good idea! Then |
I like the idea of having a I personally would rather vote for using "camelCase" as default and documenting the option for projects deciding to be more strict or wanting to use in-dom templates. |
Please describe what the rule should do:
The proposed linter rule should allow limiting the casing for slot names.
For example in bigger projects it might happen that people mix camelCase and kebab-case for the names of component slots. To keep the codebase uniform it would be really helpful if a linter rule would warn or optionally even automatically fix invalid slot names according to the projects configuration.
What category should the rule belong to?
[x] Enforces code style (layout)
[ ] Warns about a potential error (problem)
[ ] Suggests an alternate way of doing something (suggestion)
[ ] Other (please specify:)
Provide 2-3 code examples that this rule should warn about:
Bad:
Good:
Good:
Additional context
It would most likely be enough to detect invalid slot names when a slot is defined. While fixing invalid usage of slots would be nice for existing projects adapting the rule but might also blow up it's complexity.
The text was updated successfully, but these errors were encountered: