Lint #4137
Replies: 2 comments
-
The current status is that we're ignoring lots of TypeScript and SCSS linting warnings. It would be great to fix that. If it's in a separate PR, that would be easy to review. We've been much stricter with linting python. We're only ignoring a 1 or 2 warnings, namely line lengths. |
Beta Was this translation helpful? Give feedback.
-
Yup, as mentioned currently we are skipping over a lot of warnings. A big reason is also that by the time we added linting, much of the current warnings were already there. It would be nice to fix these over time. Usually, when I am working on a file I try to fix all the warnings for that file at the same time, but this is quite slow. One big PR with a bunch of lint fixes / a few big ones would be great! We can also switch the warnings over to errors for each app/library independently once each is cleaned up to prevent accumulation going forward. |
Beta Was this translation helpful? Give feedback.
-
Quick question: The developer guide recommends linting changes, but I notice when I run lint locally we have a lot of warnings already. Is this the current status, or am I linting with a stricter rule set than necessary? Do we want to eliminate warnings or just lint errors? I'd be happy to spin up a PR to eliminate a bunch of the easiest ones, like inserting explicit 'public' and 'void' for the implicitly public functions and implicitly void returning functions respectively. This would clear up the lint output to make it a little easier to target any warnings that are actually ambiguous or require source knowledge to resolve. However I don't want to spam you guys with a bunch of trivial reviews either if that's not something we care about 😅
Beta Was this translation helpful? Give feedback.
All reactions