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

Show effect of vue/html-self-closing rule re #172 #173

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jacobtylerwalls
Copy link
Member

Refs #172, just to spur discussion

see this particular "strongly recommended" rule here, but the point is that there are other rules at the warning level flying under radar

@@ -38,6 +38,9 @@ export default [
},
"rules": {
"semi": ["error", "always"],
"vue/html-self-closing": [
"error", { "html": { "void": "any" } }
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't like the <div> elements being touched, there should be a way to turn this off with normal: any

@chrabyrd
Copy link
Contributor

chrabyrd commented Jan 4, 2025

Yeah I'd say this deserves a larger discussion, as it deviates from the standard ruleset. If the change is agreed upon then it should also happen in core and whatnot.

On this I guess I tend to lean in the direction that it doesn't need programmatic enforcement -- nothing's breaking right?

@jacobtylerwalls
Copy link
Member Author

For sure we'd do it in core, this is just opened against lingo where we have Vue code to look at.

I guess I wouldn't say it deviates from the standard ruleset -- we have eslint-config-prettier turning off some recommended rules just for the sake of prettier compat, but they explain how to get it working again here.

And then the other rules are not shown in the diff because they're not auto-fixable, but since they're emitting warnings they are part of the standard ruleset and I think we should decide whether to turn 'em up to errors. Otherwise they just become things everybody ignores. Thoughts?

@jacobtylerwalls
Copy link
Member Author

On this I guess I tend to lean in the direction that it doesn't need programmatic enforcement -- nothing's breaking right?

That's totally fair. For another view:
https://dev.to/thawkin3/eslint-warnings-are-an-anti-pattern-33np

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants