jsx-wrap-multiline false positives

[paranoidjk]

I think the case below should not cause error:

https://github.com/ant-design/ant-design-mobile/blob/master/components/accordion/demo/basic.tsx#L13

components/accordion/demo/basic.tsx[13, 9]: Multiline JSX elements must be wrapped in parentheses

// bad
const button = <button type="submit">
    Submit
</button>;
// good
const button = (
    <button type="submit">
        Submit
    </button>
);

// why this is bad ? any reason we need wrap inner button with parentheses?
const button = (
   <div>
       <button type="submit">
          Submit
      </button>
   <div>
);

[adidahiya]

I can repro this, looks like a bug

[adidahiya]

more false positives I've found:

return [
    <button type="submit">
        Submit
    </button>,
    <button type="button">
        Cancel
    </button>
];

[IllusionMH]

Is it still can be reproduced?
Checked by replacing test/rules/jsx-wrap-multiline/test.tsx.lint with all code examples from this issue and link in original post. Win 10, tslint 4.5.1, tsc 2.2.1

Only example of bad code triggers error. Example with button in div passes lint as well as JSX Elements in array.

@adidahiya example from your last comment is false positive or false negative? I'd expect braces there too, but no lint errors at this moment.

[giladgray]

the array false positive @adidahiya mentioned above has forced me to disable this rule... we use that pattern everywhere.

[quantuminformation]

I'm getting Multiline JSX elements must be wrapped in parentheses

for

[adidahiya]

@quantuminformation yeah, that's the same as my comment above #79 (comment)

[wichert]

Another repro using React 16.2:

return (
  <>
    <div>One</div>
    <div>Two</div>
  </>
)

[rhys-vdw]

I wouldn't call this a false positive:

return [
    <button type="submit">
        Submit
    </button>,
    <button type="button">
        Cancel
    </button>
];

I prefer:

return [(
    <button type="submit">
        Submit
    </button>
), (
    <button type="button">
        Cancel
    </button>
)];

One reason is that when refactoring it's very easy to leave the trailing , after the closing tag, which can end up appearing in your rendered markup.

[Primajin]

@rhys-vdw problem with this way is that it is contradicting ESLint / Prettier rules...

[evenfrost]

render(
  <ApolloProvider client={client}>
    <Router history={history}>
      <App />
    </Router>
  </ApolloProvider>,
  document.querySelector('main') as HTMLElement,
);

Here's the code that throws false positive jsx-wrap-multiline for me.

[adidahiya]

I don't think we're going to fix this in tslint at this point. See #210 and palantir/tslint#4534. You're better off using prettier (edit: which you can already do without switching to ESLint).

[dawnmist]

Problem is that the 4.0.0 release of tslint-react no longer permits the standard prettier formatting for the reactDom.render() example, whereas they worked fine together in tslint-react 3.6.0.

Prettier removes any brackets around the JSX in the first parameter for reactDom.render, so it is not possible for:

 render(
  <ApolloProvider client={client}>
    <Router history={history}>
      <App />
    </Router>
  </ApolloProvider>,
  document.querySelector('main') as HTMLElement,
);

to be written as

render((
    <ApolloProvider client={client}>
      <Router history={history}>
        <App />
      </Router>
    </ApolloProvider>
  ),  document.querySelector('main') as HTMLElement,
);

when using prettier like tslint 4.0.0 now wants it to be. Can whatever was changed between those two versions for this particular rule & case please be reverted?

[adidahiya]

but why would you want to enable jsx-wrap-multiline when prettier is enabled?

[dawnmist]

Good question, and one I really hadn't thought a lot about previously because the two packages worked in harmony previously and now do not.

Flipping the question back - if you're trying to encourage people to use prettier instead of tslint-react, why would you introduce conflicting formatting that makes migration between the two projects require additional work when it had previously been working in harmony? Now anyone using tslint-react has had to change their render functions from a prettier-compatible format into a prettier-incompatible format, only to have them changed back again after migrating to prettier. That introduces unnecessary noise to git commit/blame histories for no real benefit, and no good reason when the change wasn't needed in the first place.

[adidahiya]

tslint-react had this rule before prettier was widely used in the typescript ecosystem and before we started using prettier in Palantir projects. all the code formatting rules in tslint & tslint-react are "legacy" rules in that sense; they are not guaranteed to play nicely with prettier. if you use tslint-config-prettier (the recommended configuration approach), you should have all formatting rules disabled in favor of prettier.