Tslint: no-duplicate-imports false positive with namespace imports

Created on 30 Oct 2017  Â·  6Comments  Â·  Source: palantir/tslint

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.

Accepting PRs Bug

Most helpful comment

Fixed by #4524! ✨

All 6 comments

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();

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).

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.

@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";

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();

Fixed by #4524! ✨

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CSchulz picture CSchulz  Â·  3Comments

Ne-Ne picture Ne-Ne  Â·  3Comments

ghost picture ghost  Â·  3Comments

mrand01 picture mrand01  Â·  3Comments

dashmug picture dashmug  Â·  3Comments