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
According to Prettier docs, it is "generally not recommended" to use eslint-plugin-prettier, versus having a separate prettier formatting workflow outside of eslint.
The link says:
The downsides of those plugins are:
You end up with a lot of red squiggly lines in your editor, which gets annoying. Prettier is supposed to make you forget about formatting – and not be in your face about it!
They are slower than running Prettier directly.
They’re yet one layer of indirection where things may break.
In my personal, I have experienced tooling like Visual Studio Code break when using eslint-plugin-prettier and auto-fixing lint issues. What I've seen is that extra lines of code will be deleted, probably because VS Code is formatting on save (by default) and then running eslint --fix, which may be formatting on the stale file. So, for most recent projects I have followed the practices outlined on the Prettier site and haven't had problems.
We may want to look into a different way of sharing prettier configuration, so that projects can adopt this package without worrying about tradeoffs.
(Writing this issue as result of a retro item for the USCSF IWalk-Web engagement.)
The text was updated successfully, but these errors were encountered:
Fine with me. I'm not entirely sure what the use of eslint --fix is now-a-days anyway with prettier. We don't actually have any rules enabled that impact it. I don't even know what it'd be (var to const or something?). We've loosened up our eslint quite a bit and we use a separate config than this.
Re:
You end up with a lot of red squiggly lines in your editor, which gets annoying. Prettier is supposed to make you forget about formatting – and not be in your face about it!
That's been the most annoying thing for me and typically requires custom configuration to work around (most editor plugins are capable of this) but that's a burden on everyone. It seems fine to just remove it entirely. We'd still use the config to disable the formatting rules I imagine.
Feel free to make the change and publish a new major version.
According to Prettier docs, it is "generally not recommended" to use
eslint-plugin-prettier
, versus having a separateprettier
formatting workflow outside ofeslint
.The link says:
In my personal, I have experienced tooling like Visual Studio Code break when using
eslint-plugin-prettier
and auto-fixing lint issues. What I've seen is that extra lines of code will be deleted, probably because VS Code is formatting on save (by default) and then runningeslint --fix
, which may be formatting on the stale file. So, for most recent projects I have followed the practices outlined on the Prettier site and haven't had problems.We may want to look into a different way of sharing
prettier
configuration, so that projects can adopt this package without worrying about tradeoffs.(Writing this issue as result of a retro item for the USCSF IWalk-Web engagement.)
The text was updated successfully, but these errors were encountered: