Skip to content

New: html-self-closing rule (fixes #31) #129

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

Merged
merged 5 commits into from
Aug 8, 2017
Merged

New: html-self-closing rule (fixes #31) #129

merged 5 commits into from
Aug 8, 2017

Conversation

mysticatea
Copy link
Member

Fixes #31.

This PR adds html-self-closing-style rule which replaces html-no-self-closing rule.
This rule would help us to unify self-closing style.

Copy link
Contributor

@armano2 armano2 left a comment

Choose a reason for hiding this comment

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

I think you are missing test case when there are some errors with default options.

@mysticatea
Copy link
Member Author

Thank you for the review.

I added more tests.

Also, I found a problem about comments then I fixed it.

@@ -0,0 +1,67 @@
# Enforce self-closing style (html-self-closing-style)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we can shorten the name to just html-self-closing?


/**
* Kind strings.
* This strings wil be displayed in error messages.
Copy link
Member

Choose a reason for hiding this comment

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

These

// ------------------------------------------------------------------------------

/**
* Kind strings.
Copy link
Member

Choose a reason for hiding this comment

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

Let's remove this comment, it sounds like Nice strings which is funny :D Kinds of strings would sound better, but it's redundant anyway.

*/
function parseOptions (options) {
return {
[KIND.NORMAL]: (options && options.html && options.html.normal) || 'never',
Copy link
Member

Choose a reason for hiding this comment

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

Seems like we could use https://github.com/letsgetrandy/brototype 😂

Copy link
Member Author

Choose a reason for hiding this comment

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

Or sindresorhus' dot-prop. However, I'm not sure if this is enough worth adding a new dependency. This may be not stylish, but I think enough readable.

*/
function isEmpty (node, sourceCode) {
const start = node.startTag.range[1]
const end = (node.endTag != null) ? node.endTag.range[0] : node.range[1]
Copy link
Member

Choose a reason for hiding this comment

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

!==

Copy link
Member Author

Choose a reason for hiding this comment

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

I love == null, this is equivalent to (x === null || typeof x === "undefined") and readable.


utils.registerTemplateBodyVisitor(context, {
'VElement' (node) {
const kind = getKind(node)
Copy link
Member

Choose a reason for hiding this comment

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

I'd keep kind simple as: normal, void, component and so on, and only reference the longer (more descriptive) name in message using e.g. getKindName(kind) {} function.

Btw. I think we should rename kind and call it for example htmlElementType or nodeType, what do you think? kind itself doesn't mean much, kind of what?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd keep kind simple as: normal, void, component and so on, and only reference the longer (more descriptive) name in message using e.g. getKindName(kind) {} function.

Hmm, I'm not sure if it increases maintainability/readability.

Btw. I think we should rename kind and call it for example htmlElementType or nodeType, what do you think? kind itself doesn't mean much, kind of what?

It's nice. My English skill is poor.

<math><mspace></mspace></math>
<math><mspace/></math>
</template>`
const anyWith = (opts) => Object.assign(
Copy link
Member

Choose a reason for hiding this comment

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

Please add empty line above

{
code: '<template><div/></template>',
output: '<template><div></div></template>',
errors: ['Disallow self-closing on HTML elements.']
Copy link
Member

Choose a reason for hiding this comment

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

What do you think about adding element name in the error?

Disallow self-closing on HTML elements (div).

</template>`,
options: [anyWith({ svg: 'always' })],
errors: [
{ message: 'Require self-closing on SVG elements.', line: 8 }
Copy link
Member

Choose a reason for hiding this comment

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

What about error on line 9?

Copy link
Member Author

Choose a reason for hiding this comment

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

No. I guess you see output property which is the result of auto-fix.

<x-test></x-test>
<x-test/>
<svg><path></path></svg>
<svg><path></path></svg>
Copy link
Member

Choose a reason for hiding this comment

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

Again line 8 and 9 are the same, is it intentional?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. It's the result of auto-fix.

@mysticatea
Copy link
Member Author

Thank you for review.

I updated this PR.

@mysticatea mysticatea changed the title New: html-self-closing-style rule (fixes #31) New: html-self-closing rule (fixes #31) Aug 7, 2017
Copy link
Member

@michalsnik michalsnik left a comment

Choose a reason for hiding this comment

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

LGTM 👍

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

Successfully merging this pull request may close these issues.

3 participants