[no-duplicates] additional new lines are generated when the list of imports to squash is long

I stubled upon a weird problem. My eslint --fix results in excessive spacing created, a few additional new lines are inserted with no reason.

I narrowed down the case to the clash of those 3 rules:

• no-multiple-empty-lines
• import/no-duplicates
• import/order

The original file:

import { One } from '../fragments/one'
import { Two } from '../fragments/two'
import { Three } from '../fragments/three'
import { Four } from '../fragments/four'
import { Five } from '../fragments/five'
import { Six } from '../fragments/six'
import { Seven } from '../fragments/seven'
import { Eight } from '../fragments/eight'
import { TypedDocumentNode as DocumentNode } from '@graphql-typed-document-node/core'
import { OneDoc } from '../fragments/one'
import { TwoDoc } from '../fragments/two'
import { ThreeDoc } from '../fragments/three'
import { FourDoc } from '../fragments/four'
import { FiveDoc } from '../fragments/five'
import { SixDoc } from '../fragments/six'
import { SevenDoc } from '../fragments/seven'
import { EightDoc } from '../fragments/eight'
export const Vars = any

The result of eslint --fix

import { TypedDocumentNode as DocumentNode } from '@graphql-typed-document-node/core'

import { One , OneDoc } from '../fragments/one'
import { Two , TwoDoc } from '../fragments/two'
import { Three , ThreeDoc } from '../fragments/three'
import { Four , FourDoc } from '../fragments/four'
import { Five , FiveDoc } from '../fragments/five'
import { Six , SixDoc } from '../fragments/six'
import { Seven , SevenDoc } from '../fragments/seven'
import { Eight , EightDoc } from '../fragments/eight'








export const Vars = any

The final configuration looks like below

{
  "plugins": ["import"],
  "parserOptions": {
    "sourceType": "module",
    "ecmaVersion": 2015
  },
  "rules": {
    "import/no-duplicates": ["error"],
    "import/order": [
      "error",
      {
        "groups": [
          [
            "builtin",
            "external"
          ],
          "internal",
          [
            "parent",
            "sibling",
            "index"
          ]
        ],
        "newlines-between": "always"
      }
    ],
    "no-multiple-empty-lines": ["error", {
      "max": 1,
      "maxEOF": 0
    }]
  }
}

I put together an example repo affected by the issue: https://github.com/ertrzyiks/import-order-multiple-empty-lines-demo

The result of eslint --fix is the following error:

12:1  error  More than 1 blank line not allowed  no-multiple-empty-lines

Examples

8 imports

A file with 8 imports to squash looks good 👍

https://github.com/ertrzyiks/import-order-multiple-empty-lines-demo/blob/main/example8.js https://github.com/ertrzyiks/import-order-multiple-empty-lines-demo/blob/main/results/example8.js

9 imports

A file with 9 imports starts to generate empty lines at the end of the imports block

https://github.com/ertrzyiks/import-order-multiple-empty-lines-demo/blob/main/example9.js https://github.com/ertrzyiks/import-order-multiple-empty-lines-demo/blob/main/results/example9.js

10 imports

A file with 10 imports starts to generate empty lines between the imports block and left-overs from merging

https://github.com/ertrzyiks/import-order-multiple-empty-lines-demo/blob/main/example10.js https://github.com/ertrzyiks/import-order-multiple-empty-lines-demo/blob/main/results/example10.js

[ertrzyiks]

I marked #2028 as ready for review. Turned out that this problem occurs with any number of imports. I guess it’s not so popular to have more than 2 duplicated imports so it was not causing any issues for most of the users.

[ertrzyiks]

I have some trouble with failing tests, they highlighted some more scenarios not covered by my change. The test cases are formatted with leading spaces like

    import ...
    import 

so removing just a new line character produces a very weird formatting. I considered reworking the test to ignore the leading spaces, but IMO it shows that the fix tries to be too smart now.

The problem occurred in autogenerated files, it may be much easier to update the generator to not produce duplicates.

Any thoughts on this @ljharb ? I’m leaning towards closing this issue as works as intended.