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

@ts-ignore not emitted to d.ts #20360

Closed
shaunc opened this issue Nov 30, 2017 · 3 comments
Closed

@ts-ignore not emitted to d.ts #20360

shaunc opened this issue Nov 30, 2017 · 3 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@shaunc
Copy link

shaunc commented Nov 30, 2017

TypeScript Version: 2.6.1
Code

I have a class deriving from a class in another package, which uses a too general type for an attribute, which I want to override. I can using @ts-ignore. However, the d.ts does not contain the @ts-ignore so another package using this package will not compile.

E.g. in foo.ts

    // @ts-ignore
    class Foo extends Bar { ... }

Expected behavior:

in foo.d.ts:

  // @ts-ignore
  declare class Foo extends Bar { ... }

Actual behavior:

in foo.d.ts:

  declare class Foo extends Bar

which triggers an error.

@mhegazy
Copy link
Contributor

mhegazy commented Nov 30, 2017

@ts-ignore silences the error that would have been reported otherwise. it has no semantic meaning. It does not make senses to include it in a .d.ts. as a matter of fact, it is wrong to do so.

The correct fix is to update your dependency definition.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Nov 30, 2017
@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.

@shaunc
Copy link
Author

shaunc commented Jan 2, 2018

The correct fix is to update your dependency definition.

The problem is that I am not in control of the dependency definition. I thought that directly using a .ts file internally and using .d.ts + .js should result in the same compiler behavior. (In other words, .d.ts + .js + .js.map should correspond 1-1 to original .ts.) From an operational point of view, @ts-ignore does have meaning, as it results in an observable different in build tool operation?

Of course I could do something like class Foo extends Bar as any -- but this seems like a much worse hack than using \\ @ts-ignore -- indeed I would have thought that conscribing any hacks as much as possible was exactly the purpose of @ts-ignore.

If it is indeed a useful feature to use within a package (I know there could be argument about that, but I assume its moot, as you indeed do support @ts-ignore), is there a good reason that it should not be used when consuming another package?

@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
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants