Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

no-duplicate-imports false positive with namespace imports #3418

Closed
Jessidhia opened this issue Oct 30, 2017 · 6 comments
Closed

no-duplicate-imports false positive with namespace imports #3418

Jessidhia opened this issue Oct 30, 2017 · 6 comments

Comments

@Jessidhia
Copy link

Bug Report

  • TSLint version: 5.8.0
  • TypeScript version: 2.6.0
  • Running TSLint via: CLI

TypeScript code being linted

import * as fooApi from 'api/foo'
import { FooContext } from 'api/foo'

with tslint.json configuration:

{
  "rules": {
    "no-duplicate-imports": true
  }
}

Actual behavior

Multiple imports from 'api/foo' can be combined into one. (no-duplicate-imports)

Expected behavior

For the rule to ignore, at least through an option, this specific case of combining namespace imports with named imports.

While default imports can be combined with named imports (import Foo, { Bar } from 'foobar'), it's not possible to combine them with namespace imports other than changing all references to refer to the namespace instead.

It is sometimes useful to import certain names of a namespace for commonly used things like types, while still accessing the less commonly used exports through the namespace object.

@adidahiya
Copy link
Contributor

Another use case might be importing symbols of the same name from different packages:

import * as fooApi from "api/foo";
import { FooContext } from "api/foo";
import * as barApi from "api/bar";

const c: FooContext = {};

fooApi.doStuff(c);
barApi.doStuff();

@mnn
Copy link

mnn commented Dec 13, 2017

Yeah, hit this error few months back and now again. The error message can be combined into one is misleading and incorrect, as demonstrated by OP (assuming we don't want to change rest of the code, especially when it's deliberate design). In my opinion there are cases this has its legitimate uses (e.g. a lot of action classes with generic names [e.g. Set, Response] to be imported with * and one utility "static" class very closely related to those actions).

@robpaveza
Copy link

Another use case is when importing modules for side effects:

import "./foo";
import { IFoo, IFooType } from "./foo";

The consideration here is that when the TypeScript compiler imports disappearing types only from a module (e.g., interfaces, type aliases, enum declarations, etc.), then the import of that module disappears. As a result, side-effects-only imports sometimes have to be emitted as well.

@DavidSouther
Copy link

@robpaveza If I were coming to your codebase fresh, I'd love to see that called out explicitly:

import {IFoo, IFooType} from './foo';
// tslint:disable-next-line:no-duplicate-any: Also import the side-effects
import "./foo";

@thdk
Copy link

thdk commented Jan 24, 2019

I got this linting error on the following snippet from firebase documentation:

import * as functions from 'firebase-functions';
import * as admin from 'firebase-admin';
import 'firebase-functions';
admin.initializeApp();

@JoshuaKGoldberg
Copy link
Contributor

Fixed by #4524! ✨

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants