noUnusedLocals not recognizing imports required by the declaration emitter

TypeScript Version: 2.8.0-dev.20180206

Search Terms:

"nounusedlocals exported using private"

Code

types.ts

export interface Product {
  name: string;
}

export function HasProductsMixin(superClass: any) {
  return class extends superClass {
    get products() : Product[] {
      return [{name: 'Pen'}];
    }
  }
}

export class Model {
}

main.ts

import {Model, HasProductsMixin, Product} from './types';

export class Repo extends HasProductsMixin(Model) {
}

Compiler invocation:

 tsc --target es2017 --noUnusedLocals --declaration types.ts main.ts

Expected behavior:

Code compiles with no errors/warnings.

Actual behavior:

main.ts(1,34): error TS6133: 'Product' is declared but its value is never read.

When I remove the offending import of Product, I receive the following error instead:

main.ts(3,27): error TS4020: 'extends' clause of exported class 'Repo' has or is using private name 'Product'.

Playground Link:
Sorry, I don't know how to create a playground requiring two source files :(

Related Issues:

revisit --noUnusedLocals with "export types can't be named" #13694 revisit --noUnusedLocals with "export types can't be named"
XXX has or is using name 'Foo' from external module "../bar" but cannot be named #9944 XXX has or is using name 'Foo' from external module "../bar" but cannot be named

Duplicate of #9944.

Please see the explanation of the current behavior in #9944 (comment).

The fix is tracked by #9944.

A workaround would be to add a type assertion using Product in your extends clause, e.g. (HasProductsMixin(Model) as { new(): Model & { readonly products: Product[] } })

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@mhegazy) thank you for your quick response providing a workaround! I think this issue can be closed as a duplicate now?

A workaround would be to add a type assertion using Product in your extends clause, e.g.

(HasProductsMixin(Model) as { new(): Model & { readonly products: Product[] } })

Uff, that's a rather ugly workaround, to be honest. What if the mixin class adds several additional fields and method? I don't want to repeat them in every place where I am consuming the mixin. Looks like there is a simple solution though:

// in types.ts
export interface HasProducts {
  readonly products: Product[];
}

// in main.ts
export class Repo extends 
  HasProductsMixin(Model) as { new(): Model & HasProducts }) 
{
}

It makes me wonder: is it possible to modify HasProductsMixin definition to explicitly annotate its outcome as implementing HasProducts interface, in a way that would enable TypeScript compiler to figure out how to add the required (and missing) import of Product? Or is the offered workaround the best solution until #9944 is fixed?

I tried the following but it's not enough (I still need your workaround to suppress noUnusedLocals error):

 export function HasProductsMixin(superClass: any) {
    return class extends superClass implements HasProducts {
      get products() : Product[] {
        return [{name: 'Pen'}];
      }
    }
  }

(Strangely enough, the compiler does not complain about the fact that my original "main.ts" is not importing HasProducts interface, it complains only about the missing Product import.)

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Navigation Menu

Repository navigation

noUnusedLocals not recognizing imports required by the declaration emitter #21673

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

noUnusedLocals not recognizing imports required by the declaration emitter #21673

Description

Activity

mhegazy commented on Feb 6, 2018

bajtos commented on Feb 9, 2018

typescript-bot commented on Feb 26, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions