Use the `source.sortImports` code action instead to avoid deleting "unused" imports
See original GitHub issueThe source.sortImports
code action is similar to the what organize imports does, except it doesn’t doesn’t remove “unused” imports.
Automatic removal of “unused” imports by a Prettier plugin is unacceptable, for a few reasons:
-
Automatically deleting imports that could have intended side-effects is more risky than just reordering them.
-
It destructively modifies the code you are working on. Often you begin writing a new module by writing the imports you expect to use, then start writing the module code. If you trigger a Prettier format at any point (e.g. by saving the file) before you have used all the imports in your module code, the imports unhelpfully get stripped out.
-
It destroys JS code examples in markdown readme files that demo how to import things. In these situations the imports are expected to be unused, since the JS is just an example snippet. The result after running Prettier on the markdown is all the JS fenced code blocks containing just imports are empty. Here is an example of “unused” imports within markdown:
I’ve found it difficult to reliably reproduce when the TS language server considers the imports “unused”, when using Prettier with your
prettier-plugin-organize-imports
in a VS Code editor open to a markdown file with JS fenced code blocks containing single import statements, they don’t get deleted on format. But, the exact same markdown when Prettier formatted programmatically as part of thejsdoc-md
readme generation does result in deleted imports.
Somewhat related:
Issue Analytics
- State:
- Created 2 years ago
- Reactions:6
- Comments:8 (5 by maintainers)
Top GitHub Comments
I would totally love to see this implemented. I press ctrl-s all the time just for the sake of it (habit “from the old days”) and sometimes I lose my imports unintentionally. I’ll try to find some time at the weekend to raise a PR but … no promises.
Sorry not sorry that I disagree 🙃 Not sure why you think it’s a good way to start an issue like this… “unacceptable” is a pretty hostile word for something that currently 337 people have starred because apparently they find it very useful 🤷🏻♂️
Please read the disclaimer in the readme. Using modules for global side effects is not a good practice IMO and should just be avoided. Side-effects-only imports (e. g.
import 'foo'
) are not removed bysource.organizeImports
afaik. If you’re relying on side effect imports a lot, then this plugin is the wrong choice for you. Also, reordering side-effect imports actually sounds more risky to me, because with side-effects the order might actually matter (e. g. modularfirebase
imports).I totally don’t write code like that and if you do, then yeah this plugin is probably not the best option for you. You might be better off using trivago’s prettier-plugin-sort-imports which has a very different approach and is way more configurable.
I write code by just writing the code and letting VS Code auto-import the modules as I type, and I only save when I’m done with something I want to run (shout-out to VS Code Hot Exit). Because of that, this plugin is perfect for my way of working (and many others it seems). In my opinion it would suck if I had to manually remove unused imports (e. g. if I imported stuff temporarily to try something out). I barely look at the imports anymore and it’s made my coding life a lot easier.
I’ve also done a lot of code reviews and people forgetting to remove unused imports is way too common. (Yeah linters can take care of that but also the linter’s editor plugin shouting at you while you code is very annoying)
This is the valid point I see in your issue.
For one, you can already work around this by adding a comment like this to your markdown
so that the file is skipped by the plugin.
Another possible solution going forward is to add a boolean
removeUnusedImports
config option to the plugin that switches to usingsource.sortImports
iffalse
(true
by default). I’m open to a PR for that, seems pretty straightforward.Looking at that piece of code, it might be that the inferred parser is different when running Prettier in VS Code vs running Prettier via the CLI/programmatically.