@ts-ignore not included in .d.ts file when it's needed

[SephReed]

TypeScript Version: (version check command not supplied)

Search Terms:
@ts-ignore .d.ts

Code
For reasons within my codebase, the following code absolutely necessitates // @ts-ignore in order to disable an issue in which ProxiedAny<TYPE extends object> only takes objects for TYPE. Without this line, I get the error: Type 'TYPE' does not satisfy the constraint 'object'

export function isProxied<TYPE>(checkMe: TYPE | Sourcified<TYPE>)
  // @ts-ignore 
  : checkMe is ProxiedAny<TYPE>
{
  return checkMe && typeof checkMe === "object" && "_proxied" in checkMe;
}

Expected behavior:
When compiling, I would expect to find this //@ts-ignore included with the .d.ts file.

Actual behavior:
The .d.ts file is broken:

Alternatives:
Maybe arg is TYPE should be able to do something like arg as unknown is TYPE in order to get around this issue. I'm checking if it's an object, and need a way to tell Typescript so.

[RyanCavanaugh]

ts-ignore does not imply anything other than hiding the error; any downstream effects of the error will still be present

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[SephReed]

This is definitely broken. You just don't understand what I'm saying.

[RyanCavanaugh]

@SephReed if you're not going to provide information to help me understand, what do you expect to happen?

[SephReed]

Setting the tag "Working as Intended" before asking for clarity doesn't inspire much faith.

If you copy paste the code above and run tsc you will see the output .d.ts file is broken. I don't think tsc should generate broken .d.ts files. Obviously broken .js files from @ts-ignore would be user error, but .d.ts files should always be good.

[kitsonk]

I don't think it changes the answer, but what I believe @SephReed is saying is that they believe that when compiling a .ts file with "declaration": true that any // @ts-ignore pragmas should be copied to the emitted .d.ts file, in order to preserve the intent of the original .ts code.

Of course they could simply write the code properly in the first place, instead of just ignoring errors:

export function isProxied<TYPE extends object>(checkMe: TYPE | Sourcified<TYPE>): checkMe is ProxiedAny<TYPE>
{
  return checkMe && typeof checkMe === "object" && "_proxied" in checkMe;
}

[RyanCavanaugh]

I haven't heard anything that contradicted my initial understanding of the issue.

@ts-ignore silences errors at the use site and does nothing else; this is exactly its intended behavior.

It's not a magic spell that will cause all downstream effects of that error to go away. We don't know what your intent of ts-ignore was when you used it; maybe your .d.ts file targets some environment where that code will end up being valid. I would consider this particular use of ts-ignore to be incorrect.

These were exactly the kinds of things we cautioned would be limitations of ts-ignore when we added it and people told us it would be fine, no one would misapprehend what it was for, but here we are 🤷‍♂️

[SephReed]

Of course they could simply write the code properly in the first place, instead of just ignoring errors:

I know you aren't working with my codebase, so you can't know this, but isProxied<TYPE extends object> does not fit the bill. It needs to be able to take any reference at all and tell if it is proxied.

---

If I import a .ts file that includes a @ts-ignore that relates to typing, then compile it with tsc, then import the exact same file again using a .js and .d.ts combo, it should work the same. Nothing about the typing should change between the .ts file and the .d.ts file.

---

I understand that I'm working on edge cases, and that it's really just a problem for me. But please don't say that .d.ts having different typings from the .ts files they were generated from makes any sense at all.

[SephReed]

In the end, I have made very, very rare use of @ts-ignore, so it's super simple to add a post-build script to just reinject it into the typing files.

It's a problem solved for me. If you guys don't care that .d.ts files have different typings from .ts in this case, that's up to you.