You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes our ESLint config and Prettier want 2 different things.
Generally the correct thing is to run ESLint --fix first, because ESLint autofixes will sometimes leave the code indented in weird ways, and then you run Prettier. But the next time you run ESLint, it will complain about a missing comma (because Prettier happily removed it.)
exporttypeMfaUserMethodsResponse=[{name: 'app';is_primary: boolean;is_active: boolean;date_created: string;date_modified: string;date_disabled: string;},// ESLint disagrees with Prettier about this comma.];
We could continue to handle these cases by trying to make Prettier and ESLint agree. But there may be value in separating concerns here.
What if we turn off all "styling" ESLint rules, and delegate this to Prettier?
Advantages:
Better signal-to-noise ratio in 'warnings'. Useful rules like no-undef stand out more.
Could shorten the ESLint config
?
Editor won't bug you about things Prettier can fix on save. (But maybe this is a good thing.)
The bluntest way to do it is use prettier/eslint-config-prettier to simply override any conflicting ESLint rules, without even changing the rest of our ESLint config. The "right thing" (more work, could be a separate issue) would be to take the opportunity to shorten our ESLint config.
The text was updated successfully, but these errors were encountered:
Sometimes our ESLint config and Prettier want 2 different things.
Generally the correct thing is to run ESLint --fix first, because ESLint autofixes will sometimes leave the code indented in weird ways, and then you run Prettier. But the next time you run ESLint, it will complain about a missing comma (because Prettier happily removed it.)
We could continue to handle these cases by trying to make Prettier and ESLint agree. But there may be value in separating concerns here.
What if we turn off all "styling" ESLint rules, and delegate this to Prettier?
no-undef
stand out more.The bluntest way to do it is use prettier/eslint-config-prettier to simply override any conflicting ESLint rules, without even changing the rest of our ESLint config. The "right thing" (more work, could be a separate issue) would be to take the opportunity to shorten our ESLint config.
The text was updated successfully, but these errors were encountered: