Conversation
.editorconfig
Outdated
|
|
||
| # Tab indentation (no size specified) | ||
| [*.json] | ||
| indent_style = tab |
There was a problem hiding this comment.
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.
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.
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.
Note that we now use prettier for all file types that it supports
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
ah, I suppose you want to run black after flynt anyway
There was a problem hiding this comment.
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