prettier-eslint VS eslint-plugin-import

Use the other one, prettier-eslint this is so that the code goes through Prettier before ESLint and not the other way around causing it to show issues that will be fixed once ESLint fixes it.

Same, I can't stand some of prettier's opinions/style conversions and they refuse to add more options to their config file, so people literally have to make an entirely separate plugin just to deal with the issue of its config not being able to match your eslint config.

prettier-eslint

side note: you can use prettier-eslint (as opposed to the prettier eslint plugin) which runs prettier and then eslint --fix. that way you won't get annoyed by a shit ton red lines from eslint linting with prettier.

And I just ripped out my prettierrc/prettier recently, and still need some tweaking in this area, and might even add it it back. After looking at that plugin, it looks like it just DISABLES things in ESLint that Prettier handles, so you might have to add the prettier script and a .prettierrc config file. At least that is how I understand it. I was just looking at prettier's docs and saw this though - https://github.com/prettier/prettier-eslint, which seems like it might be what you are looking for.

[2]: https://github.com/import-js/eslint-plugin-import/pull/2447#...

Finally, I'd also suggest requiring named exports via import:

eslint-plugin-import

You can 1. use a rule like this one to ensure that no one imports from antd and 2. limit what they can import from your library via https://nodejs.org/api/packages.html#main-entry-point-export

I'd check the eslint docs. They usually have a little write up about the rule.

Next, you add the ESLint rule or TypeScript configuration so it never happens again.

Are you using Eslint? It is possible to remove all the unused import on file level, but I don't remember if the setting is in the recommend config or the import/ordef plugin. If configured correctly, VS Code will prompt you with an option (CTRL+.) to "Delete all unused imports". It's only on file level though.

Prefer default export (from airbnb style guide) I did drop default exports for a year now to use only named exports and they are actually (a slightly) better option. They provide a better DX, since you'll have autocomplete. The downside can be conflicts (which can be solved using an as to rename it). Don't refactor your entire codebase just to use it, but keep in mind for the next projects that named exports has better tradeoffs.

Yeah, the code under server should never get included unless you were to (transitively) import it from your entry point like App.tsx. Small suggestion, this is a good candidate for an ESLint rule if you use that.