The current code style config for spacing is a bit of a mess and was hastily setup while getting a bunch of other things to work. Doing this was pushed ahead but it does cause some inconvenience, and will definitely if someone else tries to work with the code and is used to a completely configured project.
In order to keep individual commits clean, a lot of the time code style violations were not fixed as they would obscure changes to the application behavior. The code style config files also very much need to be brought to whatever is today's commonly used way of doing things... Keeping up with this while keeping everything working is a nightmare as these things change completely every year.
Often the generally used code style rules really don't work that well. For instance, when returning a component the JSX gets wrapped into parentheses, just so that you can align the starting tag, and for that you add 2 lines and a level of indentation. At least in code style that it was setup with a few years ago. I think this is still what everyone does but it would be nice not to do it.
In the current setup, there's probably some differences between .js and .ts code style rules.
As for "enforcement" of types, this is intentionally not enabled, because otherwise you hastily slap some types on it just to shut up the compiler and be able to run something you might delete immediately anyway. My approach to adding TypeScript is to start with the smallest things that give the most result. After doing those, you'll find that many places don't need types anymore, because they're already flowing from one place to another.
This has the "help wanted" and "good first issue" label because addressing this would make any other collaboration easier, and it would save me a lot of time.
The current code style config for spacing is a bit of a mess and was hastily setup while getting a bunch of other things to work. Doing this was pushed ahead but it does cause some inconvenience, and will definitely if someone else tries to work with the code and is used to a completely configured project.
In order to keep individual commits clean, a lot of the time code style violations were not fixed as they would obscure changes to the application behavior. The code style config files also very much need to be brought to whatever is today's commonly used way of doing things... Keeping up with this while keeping everything working is a nightmare as these things change completely every year.
Often the generally used code style rules really don't work that well. For instance, when returning a component the JSX gets wrapped into parentheses, just so that you can align the starting tag, and for that you add 2 lines and a level of indentation. At least in code style that it was setup with a few years ago. I think this is still what everyone does but it would be nice not to do it.
In the current setup, there's probably some differences between
.jsand.tscode style rules.As for "enforcement" of types, this is intentionally not enabled, because otherwise you hastily slap some types on it just to shut up the compiler and be able to run something you might delete immediately anyway. My approach to adding TypeScript is to start with the smallest things that give the most result. After doing those, you'll find that many places don't need types anymore, because they're already flowing from one place to another.
This has the "help wanted" and "good first issue" label because addressing this would make any other collaboration easier, and it would save me a lot of time.