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

noUnusedLocals not recognizing imports required by the declaration emitter #21673

Closed
bajtos opened this issue Feb 6, 2018 · 3 comments
Closed
Labels
Duplicate An existing issue was already created

Comments

@bajtos
Copy link

bajtos commented Feb 6, 2018

TypeScript Version: 2.8.0-dev.20180206

Search Terms:

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:

@mhegazy
Copy link
Contributor

mhegazy commented Feb 6, 2018

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[] } })

@mhegazy mhegazy added the Duplicate An existing issue was already created label Feb 6, 2018
@bajtos
Copy link
Author

bajtos commented Feb 9, 2018

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

@typescript-bot
Copy link
Collaborator

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

@microsoft microsoft locked and limited conversation to collaborators Jul 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants