New rule: Control empty lines around JSX tags

[jsphstls]

return (

  <button/>

)

I'd like a rule that would help eliminate empty lines around JSX. The most common case that I encounter is the above example when empty lines occur (mostly after) the JSX and before a closing parenthesis. I don't think these are ever done intentionally and I cannot see how it would improve readability.

A related case that is less common is to add blank lines between JSX:

return (
  <div> 
    <button/>

    <button/>
  </div>
)

This is often done intentionally. I am less concerned about these cases. However, I think they create ambiguity around whether those line breaks are intended to render. I also think that any component that requires spacing within the JSX should be simplified.

I did pursue a way to fix this without this plugin via padding-line-between-statements but since Eslint core no longer takes styling changes I was bounced over here.

[ljharb]

This might be a duplicate of #2630, which #2693 might solve?

[jsphstls]

Thanks @ljharb , that issue and PR appear to add lines with no configuration options. My goal is the opposite.

The PR looks like good work though. I would not want to impede it by asking for more.

[ljharb]

@jsphstls after that PR, can you help me understand what would you still be unable to do?

[jsphstls]

@ljharb I would be unable to automatically remove extra lines around and between JSX elements.

Invalid:

return (

  <button/>

)

Valid:

return (
  <button/>
)

[ljharb]

I see - so essentially, that PR adds jsx-newline which by default ensures lines, and you’d like a configuration option that removes them?

That seems like a reasonable option to add, either directly to that PR or as a follow up. Would you be interested?

[jsphstls]

Sure, I can try it after that merge.

[lukasgjetting]

@jsphstls Did you make progress on this?

[jsphstls]

@lukasgjetting thank for the reminder.

I am working on the MR to make this rule reversible. However, I am seeing some odd behaviour with the presence of   that is making this tough to verify with my own local code. It seems to depend on the parser.