You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For jsx-closing-bracket-location (tag-aligned), if the last prop is declared on the same line as the opening bracket, the rule expects the closing bracket to be after the last prop even when the last prop spans multiple lines:
constMyComponent=()=>(<div><divclassName={["some","stuff",2]}>{/* expected error, but passes lint */}
Some text
</div><divclassName={["some","stuff",2]}>{/* expected to pass, but produces error */}
Some text
</div></div>);
The error is correctly reported when the prop is moved to the next line:
<divclassName={["some","stuff",2]}>{/* errors here, as expected (closing bracket should be aligned with opening bracket) */}
Some text
</div>
I mostly agree with the examples above. However I think it should also be possible to configure following to be valid which is no longer possible with the change (e2f72f1):
// I want to write:<Compflag={true}style={{color: 'blue'}}>
child
</Comp>// eslint wants:<Compflag={true}style={{color: 'blue'}}>child</Comp>// I agree should not be valid:<Compflag={true}style={{color: 'blue'}}>
child
</Comp>
I like to follow the rule that opening braces that are on the same line should have their corresponding closing braces on the same line. non-JSX analogy:
// good:_.forEach(list,l=>({prop: l.prop}));// not so good:_.forEach(list,l=>({prop: l.prop}));
Although I don't use that style I agree that contents of braces/parens/brackets should always be indented one level deeper than the lines containing the marks, when multiline.
For jsx-closing-bracket-location (tag-aligned), if the last prop is declared on the same line as the opening bracket, the rule expects the closing bracket to be after the last prop even when the last prop spans multiple lines:
The error is correctly reported when the prop is moved to the next line:
Here's my eslint config:
I've done a quick look at the source with @captbaritone - if I find a solution I'll make a PR.
The text was updated successfully, but these errors were encountered: