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
The import/no-duplicates rule will report this, then perform the following autofix:
import{a,b,a,c}from'module'
I would expect it to remove duplicates, so the output would be:
import{a,b,c}from'module'
In my experience this is common when resolving merge conflicts if two branches added a new member to the import statement. It’s easy to Accept both changes, then let ESLint autofix resolve any issues with the imports. However, afterwards one has to remove the duplicates manually.
The text was updated successfully, but these errors were encountered:
That seems like a good approach. One could be renamed ofc, in which case both would need to be kept, but when neither has a rename, or when they both have the same one, the autofix should be collapsing them.
Let’s say we have the following content:
The
import/no-duplicates
rule will report this, then perform the following autofix:I would expect it to remove duplicates, so the output would be:
In my experience this is common when resolving merge conflicts if two branches added a new member to the import statement. It’s easy to Accept both changes, then let ESLint autofix resolve any issues with the imports. However, afterwards one has to remove the duplicates manually.
The text was updated successfully, but these errors were encountered: