Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[import/no-duplicates] (prefer-inline) Autofix merges imports incorrectly #2792

Closed
KirillGalimov opened this issue Jun 5, 2023 · 5 comments · Fixed by #3033
Closed

[import/no-duplicates] (prefer-inline) Autofix merges imports incorrectly #2792

KirillGalimov opened this issue Jun 5, 2023 · 5 comments · Fixed by #3033

Comments

@KirillGalimov
Copy link

Config:

'import/no-duplicates': ['error', { 'prefer-inline': true }]

Case 1:

input

import type { TypeOne, TypeTwo } from './types';
import type { TypeThree, TypeFour } from './types';

output

import type { TypeOne, TypeTwo, type TypeThree, TypeFour } from './types';

expected

import { type TypeOne, type TypeTwo, type TypeThree, type TypeFour } from './types';

Case 2:

input

import type { TypeOne, TypeTwo } from './types';
import { type TypeThree, type TypeFour } from './types';

output

import type { TypeOne, TypeTwo, type TypeThree, type TypeFour } from './types';

expected

import { type TypeOne, type TypeTwo, type TypeThree, type TypeFour } from './types';
@kevinbosman
Copy link

Another broken prefer-inline autofix case, and a minor inconsistency:

Case 1: Merging type followed by non-type generates uncompilable code:

input

import type { TypeOne } from './other';
import { functionOne } from './other';

output

import type { TypeOne , functionOne } from './other';

expected

import { type TypeOne, functionOne } from './other';

Case 2: Merging non-type followed by type generates correct code but with unusual output spacing:

input

import { functionOne } from './other';
import type { TypeOne } from './other';

output

import { functionOne ,type  TypeOne } from './other'

expected

import { functionOne, type TypeOne } from './other'

@dylang
Copy link

dylang commented Sep 27, 2023

Another one:

input

import type React from 'react';
import { useId, useState } from 'react';

output

import type React, { useId , useState } from 'react';

expected

import type React from 'react';
import { useId, useState } from 'react';

@frantic1048
Copy link

Another case: Merging import type and type only named import results into uncompilable code.

input

import type Highcharts from 'highcharts'
import { type SankeyNodeObject } from 'highcharts'

output

import type Highcharts, { type SankeyNodeObject } from 'highcharts';

expected

import { type default as Highcharts, type SankeyNodeObject } from 'highcharts';

Caution: Although following code looks similar to expected output, it will generate different compiled code from input when verbatimModuleSyntax is enabled in TypeScript compiler options.

import type { default as Highcharts, SankeyNodeObject } from 'highcharts';

@ben-eb
Copy link

ben-eb commented Mar 13, 2024

Ran into this today. Original code:

import type { Knex } from 'knex';
import knex from 'knex';

Produces these warnings:

index.ts:3:27
✖    3:27  /project/node_modules/knex/knex.js imported multiple times.    import/no-duplicates
✖    4:18  /project/node_modules/knex/knex.js imported multiple times.    import/no-duplicates

Auto-fixes to:

import knex, type { Knex } from 'knex';

Then when running eslint again:

index.ts:3:13
✖  3:13  Parsing error: { expected.  

1 error

And also produces the following TypeScript error:

index.ts:3:28 - error TS1434: Unexpected keyword or identifier.

3 import knex, type { Knex } from 'knex';

@yuhr
Copy link

yuhr commented Apr 5, 2024

I'd +1 to @frantic1048's expectation rather than @dylang's, as per the rule name no-duplicates, though this should be configurable by a boolean option like mergeTypeDefault with the default value being true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

7 participants