-
-
Notifications
You must be signed in to change notification settings - Fork 92
Add pre-commit #637
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
Add pre-commit #637
Conversation
.editorconfig
Outdated
|
|
||
| # Tab indentation (no size specified) | ||
| [*.json] | ||
| indent_style = tab |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what we're already using in most of our .json files, so I figured I'd formalize it here. Any objections? cc/ @Will-Sommers @AndreasArvidsson @phillco
.editorconfig
Outdated
| @@ -0,0 +1,27 @@ | |||
| # EditorConfig is awesome: https://EditorConfig.org | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is the most generic way I know to set formatting preferences, so I argue we should use it as far as possible. It is respected by Prettier, so pre-commit will automatically apply these settings via Prettier
| "extends": [ | ||
| "prettier" | ||
| ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let prettier handle all the formatting; eslint just checks for / fixes problems
| "[typescript]": { | ||
| "editor.defaultFormatter": "esbenp.prettier-vscode" | ||
| }, | ||
| "editor.defaultFormatter": "esbenp.prettier-vscode", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we now use prettier for all file types that it supports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you confirmed that it's not trying to use prettier for python for example. "that it supports" it's not something I would rely on to work automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I just tried saving and it seems to be using black
| "recommendations": [ | ||
| "dbaeumer.vscode-eslint" | ||
| "dbaeumer.vscode-eslint", | ||
| "esbenp.prettier-vscode" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will probably be nice for new contributors
| export function selectionsToSelectionInfos( | ||
| document: TextDocument, | ||
| selectionMatrix: Selection[][], | ||
| selectionMatrix: (readonly Selection[])[], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like our typescript version got bumped when I bumped yarn.lock, so now we need to be stricter about readonly
| editors.unshift(vscode.window.activeTextEditor); | ||
| editors = [ | ||
| vscode.window.activeTextEditor, | ||
| ...vscode.window.visibleTextEditors.filter( | ||
| (editor) => editor !== vscode.window.activeTextEditor | ||
| ), | ||
| ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't use unshift on a readonly array
| "js-yaml": "^4.1.0", | ||
| "mocha": "^8.1.3", | ||
| "npm-license-crawler": "^0.2.1", | ||
| "prettier": "2.6.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big thing but if you want to add the ability to shift up rather have a strict peg, that would be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to pin prettier in the package.json to the same version in the pre-commit config. As long as we remember to bump this whenever it gets bumped in the pre-commit config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm it's a bit of a bummer to have to specify prettier version in two places. I wonder if that's avoidable? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I've now pinned everything in package.json that's specified in the pre-commit config, but that seems not great. I wonder if there's a better way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll open an issue on their repo and see what comes of it. I think that duplicating it is the path forward for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this is the resolution. The tldr; is to rely on a repository local hookand throw the check into an npm or yarn script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, given that currently eslint is already run in CI, the eslint --fix isn't buying us a ton, so probably not worth the effort. Let's remove the eslint fixer for now, and wait until we start using it to remove unused imports in #640. I've added a note to that issue so we remember.
I think it's ok to leave prettier pinned until then as well. It was mainly the pinned eslint typescript parser plugin making me nervous
Sound good?
|
Looks great to me. |
| "js-yaml": "^4.1.0", | ||
| "mocha": "^8.1.3", | ||
| "npm-license-crawler": "^0.2.1", | ||
| "prettier": "2.6.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to pin prettier in the package.json to the same version in the pre-commit config. As long as we remember to bump this whenever it gets bumped in the pre-commit config.
|
Ok thanks for all the feedback! I think this one is good to go except for #637 (comment), so would be great if anyone has ideas there cc/ @Will-Sommers @auscompgeek |
auscompgeek
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. A couple of comments.
| # TODO: bump to --py310-plus when Talon moves to Python 3.10. | ||
| args: [--refactor, --py39-plus] | ||
| types_or: [python, markdown, rst] | ||
| - repo: https://github.com/pre-commit/pre-commit-hooks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be a good idea to move pre-commit-hooks before shed? They should be faster I think; failing fast would probably be ideal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Fwiw, though, pre-commit doesn't short-circuit, so I'm not sure there's too much benefit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I suppose you want to run black after flynt anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah exactly. And as a matter of fact I did find it useful to be able to hit Ctrl-c when running locally if I noticed failure, so I guess there is some benefit 👍.
Thanks for all the helpful comments! I'm happy with how it turned out
Adding pre-commit. To see what it looks like when we run it, see #638
See #639 and #640 for a couple minor follow-up tasks