FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Add tslint-plugin-prettier and apply code formatting by mturley · Pull Request #2810 · patternfly/patternfly-react · GitHub

Add tslint-plugin-prettier and apply code formatting - #2810

Merged
redallen merged 3 commits into
patternfly:masterfrom
mturley:chore/prettier
Oct 2, 2019
Merged

Add tslint-plugin-prettier and apply code formatting#2810
redallen merged 3 commits into
patternfly:masterfrom
mturley:chore/prettier

Conversation

mturley commented Aug 30, 2019
edited
Loading

Copy link
Copy Markdown
Contributor

What:

Because we realized that some important code-formatting-related TSLint rules are broken, @redallen and I decided that it would be appropriate to add Prettier to our linter, and run it on existing code.

This PR:

  • Adds tslint-plugin-prettier which runs Prettier as part of TSLint (currently these errors do not fail the CI checks, but eventually when other TSLint errors are resolved they probably should)
  • Re-adds tslint-config-prettier which was removed in Improve linting #2787, this disables TSLint rules which would conflict with Prettier
  • Re-adds the yarn prettier script which contributors can run to automatically format their code
  • Includes code changes from an initial run of yarn prettier and yarn lint:ts --fix. This cleans up all of our indentation issues and other small formatting gripes.

Hopefully this will help to make our code a little more readable and consistent going forward!

cc @redallen

Closes #2362 (for real this time)

mturley requested a review from redallen August 30, 2019 20:18

mturley commented Aug 30, 2019

Copy link
Copy Markdown
Contributor Author

Hmm, yarn lint:ts --fix still makes some conflicting changes. Hang on for one more commit.

Copy link
Copy Markdown
Collaborator

PatternFly-React preview: https://patternfly-react-pr-2810.surge.sh

mturley commented Aug 30, 2019

Copy link
Copy Markdown
Contributor Author

Ok, this should be all set now. I ran yarn lint:ts --fix and it had some more changes to make, then ran yarn prettier again and it made no changes, so they don't conflict.

boaz0 previously approved these changes Sep 1, 2019

boaz0 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

🎊 🎉

mturley commented Sep 4, 2019

Copy link
Copy Markdown
Contributor Author

Rebased on master

redallen commented Sep 6, 2019

Copy link
Copy Markdown
Contributor

Let's try to do get this in post code-freeze next week after one final rebase. Things are a little hectic now.

mturley commented Sep 6, 2019

Copy link
Copy Markdown
Contributor Author

Fair enough 🙂

mturley commented Sep 17, 2019
edited
Loading

Copy link
Copy Markdown
Contributor Author

(moved this comment to the bottom to track latest commits)

mturley commented Sep 17, 2019

Copy link
Copy Markdown
Contributor Author

Hmm.. @redallen I'm having trouble parsing the errors in the CircleCI log, do you know why this would be failing CI? I didn't make any different configuration changes compared to before the rebase.

Copy link
Copy Markdown
Contributor

@mturley During yarn build it's something to do with Chart types:

src/components/ChartVoronoiContainer/ChartVoronoiContainer.tsx(153,6): error TS2322: Type '{ activateData?: boolean; activateLabels?: boolean; disable?: boolean; labels?: (point: any, index: number, points: any[]) => string; mouseFollowTooltips?: boolean; onActivated?: (points: any[], props: VictoryVoronoiContainerProps) => void; ... 14 more ...; theme: ChartThemeDefinitionInterface; }' is not assignable to type 'IntrinsicAttributes & IntrinsicClassAttributes<VictoryVoronoiContainer> & Readonly<VictoryVoronoiContainerProps> & Readonly<{ children?: ReactNode; }>'.
  Property 'className' does not exist on type 'IntrinsicAttributes & IntrinsicClassAttributes<VictoryVoronoiContainer> & Readonly<VictoryVoronoiContainerProps> & Readonly<{ children?: ReactNode; }>'

Charts has been touched a lot lately, so I'd recheck the merge conflicts for that file. Worst case, checkout master's version and then relint the file.

mturley commented Sep 18, 2019
edited
Loading

Copy link
Copy Markdown
Contributor Author

Worst case, checkout master's version and then relint the file

Hmm, that's what I did (I cherry-picked only the config changes and relinted the whole repo). I'll take a closer look at that file, thanks!

// Note: theme is required by voronoiContainerMixin, but @types/victory is missing a prop type
// @ts-ignore
return <VictoryVoronoiContainer className={chartClassName} labelComponent={chartLabelComponent} theme={theme} {...rest} />;
return (

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Ahh, @redallen it looks like it was this @ts-ignore not being applied anymore because the offending code was moved down a line by prettier. I'll add a prettier-ignore on the same line, and we might have to do that in the future where we need @ts-ignore on a long line.

It's weird that we can't just ts-ignore multiple lines... looks like an open issue: microsoft/TypeScript#19573

mturley changed the title Add tslint-plugin-prettier Add tslint-plugin-prettier and apply code formatting Sep 23, 2019

mturley commented Sep 23, 2019
edited
Loading

Copy link
Copy Markdown
Contributor Author

I rebased this on the latest master, and squashed it into 3 commits to make it easier to rebase in case we need to do so again:

  • The first commit makes the actual configuration changes, this commit should be included in a rebase.
  • The second commit stops prettier from making the build fail by removing ts-ignore from a line, this commit should be included in a rebase.
  • The last commit runs the linter and formatter on existing code, this commit should be dropped and replaced in a rebase.

mturley commented Sep 23, 2019

Copy link
Copy Markdown
Contributor Author

@dgutride do you think it would make sense to try and merge this (after a final rebase) immediately after this week's code freeze ends, to minimize conflicts with other PRs? It doesn't change our dist, but it touches a lot of files.

redallen previously approved these changes Sep 23, 2019

redallen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

LGTM

dlabrecq previously approved these changes Sep 25, 2019

dlabrecq left a comment
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Not a fan of how Prettier reformats the code. Some code is less readable, IMO -- formatted for a reason. Although, the yarn lint:ts --fix is much needed. Those changes in chart changes look ok.

mturley commented Sep 26, 2019

Copy link
Copy Markdown
Contributor Author

@dlabrecq what formatting opinions of Prettier do you dislike? We can reconfigure it: https://prettier.io/docs/en/options.html. I'm not really concerned about how the code is formatted as long as it's formatted consistently. Messy indentation was my main gripe.

mturley commented Sep 26, 2019
edited
Loading

Copy link
Copy Markdown
Contributor Author

I do agree somewhat that Prettier tries too much to fit the most code into every line, but I think maybe that could be helped by lowering the print-width option. They actually recommend that you don't exceed 80 characters on that option (see the yellow box at the top of the options docs), and we have it set to 120.

I would be open to shortening this to 80 or 100 (and then obviously there would be many lines which would end up longer than that).

mturley force-pushed the chore/prettier branch 2 times, most recently from 5891669 to e201d19 Compare September 26, 2019 18:00

Copy link
Copy Markdown
Member

@mturley I often use separate lines when I destructure multiple items or sometimes when importing long names, but that's just my preference to make things more readable. It's not a big deal, just not a fan. I am a big fan of running yarn lint:ts --fix, tho

mturley commented Sep 26, 2019

Copy link
Copy Markdown
Contributor Author

I agree actually, those sound like good reasons to disagree with Prettier. We could lower the print width to make that less of an issue, and in extreme cases we could use // prettier-ignore if it's being really fussy. This PR doesn't automatically run it going forward though, so we can always run it and then change things back if we disagree with it.

mturley force-pushed the chore/prettier branch 2 times, most recently from b9d71eb to cccb4d7 Compare September 27, 2019 16:56

mturley commented Sep 27, 2019

Copy link
Copy Markdown
Contributor Author

@dlabrecq I'll bug you just one last time (I know you're not thinking of this as a big deal), but just for comparison's sake I made a few separate branches and ran the same process with the print-width set to 100 characters (mturley@c5fbfe4) and set to 80 characters (mturley@fc02c3b).

The lower the print-width, the more readable a lot of code gets, but files end up larger in terms of lines of code. Do you have an opinion on whether either of these would be better than the 120-character width in this PR?

dlabrecq previously approved these changes Sep 27, 2019

dlabrecq left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Looks better. Still some odd indentations in some places, but not a deal breaker.

? height > defaultSize
? value + (height - defaultSize) * scale
: value - (defaultSize - height) * scale
: width > defaultSize

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

This indentation looks much better compared to the others I noted

| 'triangleUp'
| 'dash'
| 'threshold'
| Function;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Better...

? defaultPadding.top * 0.5 + (defaultPadding.bottom * 0.5 - defaultPadding.bottom) - 25
: title
? -defaultPadding.bottom + 60
: -defaultPadding.bottom;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

This indentation looks a little off?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

It looks like Prettier will indent a nested ternary if it is nested within the true-branch (foo ? bar ? 1 : 2 : 3) but not if it is trailing / nested in the false-branch (foo ? 1 : bar ? 2 : 3). This is a bit weird but seems reasonable to me... to be honest though, maybe we should avoid nested ternary expressions unless we use parentheses to make them more clear. Maybe that would help here.

mturley Sep 27, 2019
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Looks like this is a subject of debate in Prettier: prettier/prettier#5814 (blog post explaining their decision to do it that way: https://prettier.io/blog/2018/11/07/1.15.0.html#flatten-else-branch-for-nested-ternaries-5039-by-suchipi-5272-by-duailibe-5333-by-ikatyang)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Huh. Adding parens around the second expression there, Prettier removes them. Maybe that's a case where // prettier-ignore would be useful if we need an exception to make that code extra clear.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I didn't realize // prettier-ignore was available. That could be quite useful for those couple of weird issues

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Agreed. You can even configure a .prettierignore file to ignore entire files/directories if necessary

jschuler previously approved these changes Sep 27, 2019
mturley dismissed stale reviews from jschuler and dlabrecq via b1f6012 September 30, 2019 21:06

mturley commented Sep 30, 2019
edited
Loading

Copy link
Copy Markdown
Contributor Author

Rebased, if you want to re-approve @jschuler @dlabrecq @redallen

redallen previously approved these changes Sep 30, 2019

mturley commented Oct 1, 2019

Copy link
Copy Markdown
Contributor Author

🎶 ...one more time... 🎶

redallen merged commit 0d072ea into patternfly:master Oct 2, 2019

Copy link
Copy Markdown
Collaborator

Your changes have been released in:

  • patternfly-react-extensions@2.20.9
  • patternfly-react-wooden-tree@2.0.5
  • patternfly-react@2.39.4
  • @patternfly/react-console@1.12.13
  • @patternfly/react-charts@5.0.15
  • @patternfly/react-core@3.112.4
  • @patternfly/react-docs@4.14.4
  • @patternfly/react-inline-edit-extension@2.11.71
  • demo-app-ts@3.6.11
  • @patternfly/react-integration@3.6.2
  • @patternfly/react-styled-system@3.6.40
  • @patternfly/react-styles@3.5.28
  • @patternfly/react-table@2.22.20
  • @patternfly/react-topology@2.8.66
  • @patternfly/react-virtualized-extension@1.2.56
  • @patternfly/react-icons@3.14.8

Thanks for your contribution! 🎉

mturley deleted the chore/prettier branch October 2, 2019 17:00
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Code style/formatting rules for TypeScript are not enforced by TSLint

7 participants


Back | FazBrowse Home | New Git URL