eslint-import-resolver-typescript VS eslint-plugin-import

eslint-import-resolver-typescript

Thanks, happy you enjoyed the article!

The PRs for the previous article were all merged. I originally wanted to do the same for this one, but I'm not sure if I have the time to fix all of them. Updating to a newer version of `resolve` already addresses the most notable issue with throwing more errors than necessary, but many parts of the ecosystem still use an old version.

Manged to land this PR in another package though https://github.com/import-js/eslint-import-resolver-typescri... . Performance there could be easily improved further there.

Another PR to an eslint plugin was unfortunately rejected as it broke node 4 support https://github.com/import-js/eslint-plugin-import/pull/2654 .

The other popular package that's used for module resolution is `enhanced-resolve` by the webpack folks and they expect the consumer to deal with passing the appropriate options. So there isn't really a single place to fix this.

[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.