chore: increase eslint/typescript strictness - #75
Conversation
c735f97 to
b2955b2
Compare
c41627e to
0623c8a
Compare
| <div className='setup-progress-label'> | ||
| {phase === 'seeding' && <span className='setup-spinner' />} | ||
| <span>{progress.label || 'Starting...'}</span> | ||
| </div> |
There was a problem hiding this comment.
The linter noticed that this was redundant, there's an external check that the phase is seeding or error already.
| import prettier from 'eslint-config-prettier/flat' | ||
| import noRelativeImportPaths from 'eslint-plugin-no-relative-import-paths' | ||
| import simpleImportSort from 'eslint-plugin-simple-import-sort' | ||
| import unusedImports from 'eslint-plugin-unused-imports' |
There was a problem hiding this comment.
I added unusedImports was added a while back so that prettier wouldn't delete unused imports, which made my workflow better. But typescript-eslint/no-unused-vars had a hidden option for removing unused imports that serves the same purpose without the dependency.
0623c8a to
453f62e
Compare
453f62e to
a597da3
Compare
a597da3 to
5ad8935
Compare
5ad8935 to
05d14a9
Compare
05d14a9 to
c2f9d4f
Compare
| }, | ||
| rules: { | ||
| '@typescript-eslint/no-unused-vars': 'off', | ||
| 'no-unused-vars': ['error', { args: 'none', caughtErrors: 'none' }], |
There was a problem hiding this comment.
| 'no-unused-vars': ['error', { args: 'none', caughtErrors: 'none' }], | |
| 'no-unused-vars': ['error', { argsIgnorePattern: '^_', caughtErrors: 'none' }], |
Would this be too disruptive? This specific lint seems useful.
There was a problem hiding this comment.
Not too disruptive and I changed it — but I actually changed it in @typescript-eslint/no-unused-vars, which seems like a better place to do it.
The relationship between @typescript-eslint/no-unused-vars and no-unused-vars is completely confusing to me though I think I once understood it.
FWIW, the reason I have this set to none in my person configurations is that
- You still get the grayed-out unused indication in vscode
- You don't get
_argstuff bleeding into interfaces for public functions that, for whatever reason, ignore their arguments. (This can happen when you change an implementation but want to leave the API stable, for example.)
There was a problem hiding this comment.
One advantage of eslint over VSCode UI features is that CI would catch typos here. Your second point about backwards compat makes sense, though. Up to you what to do here!
7154a75 to
f89eb1c
Compare
2 participants
Changes in #69, the first experiment at adding linting rules, seemed like they were dominated by adding
!annotations everywhere. Wanted to try to do something cleaner and higher-signal, though I did end up adding one noisy rule, typescript-eslint/consistent-type-imports, which insists on type imports being marked withtype.