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

Formatting #913

Closed
wants to merge 16 commits into from
Closed

Formatting #913

wants to merge 16 commits into from

Conversation

goosewobbler
Copy link
Contributor

@goosewobbler goosewobbler commented Jun 27, 2022

Using prettier, lint-staged and husky to remove formatting nits from all PRs going forward. This does not include linting, saving that for another PR.

Prettier options: https://prettier.io/docs/en/options.html

Changes

  • lint-staged runs on husky pre-commit, which runs the format script, which runs prettier on TS, JS, MD, YML, JSON files.
  • formatting can be run and checked manually with npm run format and npm run format:check
  • unit tests run on husky pre-push - so no more PRs with broken tests, and zero tolerance for flaky tests

Prettier settings

printWidth: 120 (better display on larger monitors)
singleQuote: true (single quotes used for all string literals apart from JSX)
jsxSingleQuote: true (single quotes used for all JSX string literals)
semi: false (no semicolons)

In-editor formatting

Prettier VSCode formatter - not required for development but I usually have this configured to format on save:
https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode

.prettierrc Outdated
"printWidth": 120,
"singleQuote": true,
"semi": false,
"trailingComma": "all"
Copy link
Collaborator

Choose a reason for hiding this comment

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

this is the only nit I have, I'm personally not a fan of the trailing comma though I will defer to the team's majority vote. @floating what's your stance?

Copy link
Owner

Choose a reason for hiding this comment

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

Agreed, also not a fan

Copy link
Owner

Choose a reason for hiding this comment

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

Can we also add "jsxSingleQuote": true?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removing trailing commas, it's often a contentious one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not really a fan of single quote in JSX tbh, however I can see both sides of the argument - "mirror HTML preferences" vs "JSX is not HTML". I think the double quotes help to visually distinguish between JSX string literals, string literals elsewhere and template literals in JSX. Or maybe it's just what I'm used to - React docs feature double-quoted JSX and it's the default in ESLint. Everywhere else, there's the expected endless debate:

airbnb/javascript#629
airbnb/javascript#269 (comment)
xojs/eslint-config-xo#78
prettier/prettier#1080

I'm not precious about it anyway, it's probably more of an aesthetic decision than anything, and any kind of codified formatting is better than none.

Copy link
Owner

@floating floating Jul 3, 2022

Choose a reason for hiding this comment

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

Yeah, I think single quote consistency is better and is already the style the codebase.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added jsxSingleQuote and updated. We'll probably need to ditch all the non-config changes and recreate the PR when it is time to merge anyway; the formatting changes in this PR are just to show what the formatted code would look like with these settings.

@mholtzman
Copy link
Collaborator

one more thing is we should wait until we rebase develop off of 0.5 before we do this otherwise the rebase will be an absolute nightmare. which direction makes more sense, to do this on 0.5 and port it to develop or vice versa?

@floating
Copy link
Owner

floating commented Jul 1, 2022

I think we might actually want to wait until the first develop/canary release goes to production before making these types of changes. Also, please wait for my review on this one as well.

@@ -76,7 +76,7 @@ describe('token metadata lookup', () => {
expect(tokenDecimalsInput.value).toEqual('18')
expect(tokenChainSelect.textContent).toEqual('Mainnet')
})
}, 1000)
}, 2000)
Copy link
Collaborator

Choose a reason for hiding this comment

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

are these tests regularly taking longer than 1 second? seems like something we should address as no individual unit test should be taking anywhere near this long

Copy link
Collaborator

Choose a reason for hiding this comment

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

also please try not to pile a bunch of unrelated changes into one PR, better to make them separate PRs so we can track changes more clearly going forward

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We'll probably need to ditch all the non-config changes and recreate the PR when it is time to merge anyway; the formatting changes in this PR are just to show what the formatted code would look like with these settings.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When the tests run on every push, you know pretty quickly if they are flaky. I should have forced husky pre-push not to run rather than commit more changes. However, as mentioned above I am not expecting this will be merged, better to take the config changes and reapply formatting to create a new PR when we are ready.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Marked as draft to make the above more obvious

@goosewobbler goosewobbler marked this pull request as draft July 4, 2022 13:45
@mholtzman mholtzman added the WIP PRs that are still in progress and not ready for review or merging label Sep 26, 2022
@goosewobbler
Copy link
Contributor Author

Closing in favour of #1113

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WIP PRs that are still in progress and not ready for review or merging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants