chore: Add .editorconfig, subshell dir changes in scripts #1649
Conversation
.editorconfig
Outdated
| root = true | ||
|
|
||
| [*] | ||
| end_of_line = lf | ||
| charset = utf-8 | ||
| trim_trailing_whitespace = true | ||
| insert_final_newline = true | ||
| indent_style = tab | ||
|
|
||
| [*.{md,json,yaml}] | ||
| indent_style = space | ||
| indent_size = 2 |
There was a problem hiding this comment.
remark: I think we may need to iterate on this a bit:
- Markdown, JSON, and YAML should be fine with 2-spaces
- Prettier might not agree with tabs according to the sample editorconfig for editorconfig-core-js
- Similarly for Go, the preferred settings seem to be a bit different
There was a problem hiding this comment.
I added a .editorconfig to the site/ package that defaults to spaces, should make prettier happy and I think that's the most common indentation for site/, so we can add exceptions after they're discovered.
Re: Go, which changes do you think we should make? Except for default space, I think our settings read fairly similar. I'm OK with copying those straight off if that's the preference but I matched style of e.g. .md for what's previously used in this project.
One change I would make though is to not define indent_size for indent_style = tab because that's just evil and taking peoples preference of visual tab size away from them. 😄
|
Question: Should we add |
I'd be in favour of that, as well as |
|
Both |
| indent_size = unset | ||
|
|
||
| [node_modules/**] | ||
| ignore = true |
There was a problem hiding this comment.
Question (non-blocking): I've considered this in the past, but ultimately didn't add one because we have prettier:
https://github.com/coder/coder/blob/main/site/.prettierrc
My question is what advantages do we have from having both an editorconfig and a prettier config?
One advantage I believe is that you might not need to run prettier before submitting a PR, to say convert tabs into spaces.
(currently you'd run yarn format:write):
Line 15 in 7ac3cbe
However, a disadvantage, is that we have to duplicate logic between .editorconfig and .prettierrc.
What are your thoughts?
I'd rather leave things solely to prettier, but when I say that, I'm unaware of the pain points a prettier-only flow leaves to folx developing the FE. I'm not pushing back, but rather trying to understand the need first.
There was a problem hiding this comment.
@code-asher and @jsjoeio - I believe code-server uses an .editorconfig:
https://github.com/coder/code-server/blob/main/.editorconfig
I'm wondering if you have any insight into this question from me as well.
There was a problem hiding this comment.
It's before my time so I don't have the full context but @code-asher may be able to share some helpful context.
There was a problem hiding this comment.
For me it was because my editor reads .editorconfig but has no concept of Prettier. That said, I could probably add a plugin that adds support for reading the Prettier config. Selfishly I would prefer an .editorconfig versus having to add a new plugin but that is something I can get over. 😆 Although to be 100% honest I would probably just keep setting it manually every time I open the project like I have been for v1.
The editor support looks good for Prettier so I doubt .editorconfig has an advantage there. So in sum, it is for selfish reasons that code-server has an .editorconfig. 😝
There was a problem hiding this comment.
@vapurrmaid great questions, I'll try my best to answer them (in bulletpoints).
My question is what advantages do we have from having both an
editorconfigand aprettierconfig?
prettierchecks theeditorconfigconfiguration, so no duplication- We're implicitly relying on prettier defaults right now (2-space), this change would make it explicit
- Other tools also follow
editorconfig, e.g.shfmtwhich was added in this PR - (Absurd example) it would allow us to define tab indentation for
.shfiles in the backend, and 2-space indentation on the frontend - Can define indentation rules for files not handled by prettier (probably not relevant on the frontend atm)
- Before this PR,
.shfiles used a mix of 2-space and 4-space indentation
Finally, one less defined benefit is reduced developer churn, I'm thinking even if this only saves us from commenting on one or two PRs about indentation, that's a win. Similarly, if it helps even one person contributing to the codebase, that's a win.
But all that aside, I do acknowledge it's one more place to hide settings away, and I'm happy to remove it if that's what you prefer. We can probably even keep it only for one part of the project, if that's preferable. Recently for example the .sql formatter was removed, so having rules that say they should be tab-indented would be helpful on the backend.
There was a problem hiding this comment.
I don't think it's selfish, though, we need to have an awesome development experience for all of our developers <3 and everyone counts on that front!
I'm happy to move forward @mafredri , TIL about some of those points, thanks for taking the time to hash it out 💪🏻
There was a problem hiding this comment.
Similarly, if it helps even one person contributing to the codebase, that's a win.
This is really well said!
This PR adds a
.editorconfigfile to the project root to help contributors ensure they have the correct editor settings when contributing to the project.It also updates all
.shscripts to perform dir changes inside subshells since calling the script directly could change the callerspwd.I opted to not specify specific
.shsettings in.editorconfig, this means tabs will be the preferred indentation as with our.gofiles.PS. I recommend ignoring whitespace when reviewing.
PPS. Should we also move the
generate.shscripts toscripts/folder?