Use max-len rule. Code value in the config is default 80 and there's no way to turn it off. Hacking it with length of 420.
https://eslint.org/docs/rules/max-len
https://linear.app/comm/issue/ENG-1083/eslint-rule-for-80-char-width-comments
Details
Details
you should see errors when running yarn eslint
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- inline-sidebar-web-and-native-ENG-530
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
Discussed offline, this didn't actually do what @benschac thought it did, but he has another idea
| .eslintrc.json | ||
|---|---|---|
| 18 ↗ | (On Diff #12239) | I think it might be a good idea to mention somewhere here that the 80 character width limit that we try to maintain in our codebase (because we miss typewriters or something) is handled/enforced by prettier rather than eslint. It wasn't immediately obvious to me that setting code to 420 here wouldn't "break" the enforcement of that rule. Maybe mention that the reason we don't want to set an 80 character max-len is to avoid issues with long imports? It may also be good to change the value from 420 to something like 9999. I think being another order of magnitude above 80 makes it clear that the intention is for the value to effectively be infinity. It would also be good to use 9s instead of a number which has negative connotations. |
| .eslintrc.json | ||
|---|---|---|
| 19–22 ↗ | (On Diff #12242) | Can you clarify that Prettier is the one formatting import statements to >80 chars? Something like: // Prettier is configured to keep lines to 80 chars, but there are two issues: // - It doesn't handle comments (leaves them as-is) // - It makes all import statements take one line (reformats them) // We want ESLint to warn us in the first case, but not in the second case // since Prettier forces us in the second case. By setting code to 420, we // make sure ESLint defers to Prettier for import statements. |