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

Update: Improve report location for template-tag-spacing (refs #12334) #13203

Merged
merged 2 commits into from Jun 1, 2020

Conversation

mdjermanovic
Copy link
Member

Prerequisites checklist

  • I have read the contributing guidelines.
  • The team has reached consensus on the changes proposed in this pull request. If not, I understand that the evaluation process will begin with this pull request and won't be merged until the team has reached consensus.

What is the purpose of this pull request? (put an "X" next to an item)

[X] Other, please explain:

refs #12334

Change reported location in the template-tag-spacing rule.

What changes did you make? (Give an overview)

For "always", the rule will now report the full location of the first token before the template literal, instead of just its start.

For "never", the rule will now report range between the first token before the template literal and the template literal, instead of start of the first token before the template literal,

"always" before this change:

image

"always" after this change:

image

"never" before this change:

image

"never" after this change:

image

Is there anything you'd like reviewers to focus on?

@mdjermanovic mdjermanovic added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules accepted There is consensus among the team that this change meets the criteria for inclusion labels Apr 20, 2020
@nzakas
Copy link
Member

nzakas commented Apr 22, 2020

Thanks for doing this. For “always”, I think I’d prefer the parens and “foo” all be underlined so it matches what happens without parens.

@mdjermanovic
Copy link
Member Author

Thanks for doing this. For “always”, I think I’d prefer the parens and “foo” all be underlined so it matches what happens without parens.

This can be done by reporting range from the start to the quasi, which is basically everything that makes the tag in a tagged template literal.

Some examples:

image

and a typescript example with generics:

image

Does it look okay, or is it maybe underlining too much code?

Another alternative might be to report loc of the left backtick.

@kaicataldo
Copy link
Member

Another alternative might be to report loc of the left backtick.

This makes sense to me!

@nzakas
Copy link
Member

nzakas commented May 5, 2020

I still like my suggestion better. :) It’s difficult time see underlines of just one character.

@mdjermanovic
Copy link
Member Author

"always" is changed now:

image

Copy link
Member

@nzakas nzakas left a comment

Choose a reason for hiding this comment

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

I like it! @kaicataldo are you okay with this?

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!

@kaicataldo kaicataldo merged commit b76aef7 into master Jun 1, 2020
@kaicataldo kaicataldo deleted the templatetagspacing-loc branch June 1, 2020 19:14
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Nov 29, 2020
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Nov 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants