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

Fatal on error has or is using private name on an already export-ed Class #3173

Closed
huan opened this issue Aug 28, 2017 · 5 comments
Closed

Comments

@huan
Copy link

huan commented Aug 28, 2017

Bug Report

  • TSLint version: 5.7.0
  • TypeScript version: 2.4.2
  • Running TSLint via: CLI

TypeScript code being linted

import {
  widget,
  Widgets,
}             from 'blessed'

declare module 'blessed' {
  namespace widget {
    class Image extends Widgets.ImageElement {}
  }

  namespace Widgets {
    interface Border {
      top?:    boolean,
      bottom?: boolean,
    }
  }
}

with tslint.json configuration:

tslint --project tsconfig.json --type-check 

Actual behavior

[ts] 'extends' clause of exported class 'Image' has or is using private name 'Widgets'.

However, ts-node & tsc can run the code without any problem.

Expected behavior

Should not show private name Widgetsbecause it's alreadyexport`-ed.

@ajafff
Copy link
Contributor

ajafff commented Sep 5, 2017

The quick fix for your problem is omitting --type-check. It's no longer needed to use type checked rules.
You will then no longer see any compile errors in the lint output.

@huan
Copy link
Author

huan commented Sep 6, 2017

Yes, that's what I did at last.

But what do you mean "it's no longer needed", had --type-check deprecated?

It's no longer needed to use type checked rules.

@ajafff
Copy link
Contributor

ajafff commented Sep 15, 2017

--type-check is not deprecated yet. It's just no longer needed for typed rules to work, --project is sufficient for that.

It probably will be deprecated. It's no longer useful and we frequently get bug reports about it. I don't think it's worth keeping it around.

@huan
Copy link
Author

huan commented Sep 16, 2017

It's a good news that --project is sufficient for checking.

Thanks for the explanation!

@huan huan closed this as completed Sep 16, 2017
@trusktr
Copy link

trusktr commented Dec 21, 2019

I've opened a request to fix issues like these in TypeScript by bringing declaration files to parity with language features. microsoft/TypeScript#35822

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

No branches or pull requests

3 participants