fix: unable to evaluate instanceof AjaxError

[voliva]

Description:

Because the constructor signature of AjaxErrorCtor and AjaxTimeoutErrorCtor are marked as @internal, and #6215 added stripInternals: true, the interface of these two constructors was exported as an empty interface.

Typescript would then complain on projects that use error instanceof AjaxError, as it doesn't identify AjaxError as callable.

Related issue (if exists): #6269

I've found this solution, which I think works nicely: The type is still exported, the constructor signature is still stripped (because it's internal) and typescript now allows to check instanceof AjaxError, while preventing the consumer from trying to call the constructor:

[cartant]

Thanks. You'll need to do npm run api_guardian:update, too.

Ignore that. I'd expected this to remove the @internal, but if the extend Function works, I suppose that's okay. Does it really work?

[voliva]

Thanks. You'll need to do npm run api_guardian:update, too.

Ignore that. I'd expected this to remove the @internal, but if the extend Function works, I suppose that's okay. Does it really work?

Mhh now I see that although it does fix the instanceof issue, TS guards fail:

if(error instanceof AjaxError) {
  // typeof error = { }
}

I'll try to give it a bit more thought see if I can keep both (i.e. internal on types, while being able to use typescript guards), otherwise I'll just remove the @internal annotation.

[voliva]

by the way, npm run api_guardian:update doesn't seem to have any effect on these interfaces: For some reason they are not getting exposed in the api_guard folder, even when removing @internal

[cartant]

For some reason they are not getting exposed in the api_guard folder, even when removing @internal

Yeah, you're right. It's only the AjaxError that's exported; the ctor type is not.

[voliva]

I just changed to the simple "remove @internal tags" solution.

I did find a solution that would work, but doesn't feel right

export interface AjaxErrorCtor {
  /**
   * Internal use only. Do not manually create instances of this type.
   */
  new (internal: never): AjaxError
  /**
   * @internal
   */
  new (message: string, xhr: XMLHttpRequest, request: AjaxRequest): AjaxError;
}

And guards work fine. But I don't fully like it.... also when using it within rxjs you'd also see that fake signature. So I gave up - I removed the internal tag.

[cartant]

So I gave up - I removed the internal tag.

That's fine. There are a whole bunch of other XErrorCtor interfaces and most don't have an @internal tag.

[benlesh]

Why would people need to create their own new AjaxError? This was made internal intentionally, IIRC. It's fine for instanceof checks. I wish I could stop inheritance... But I can't see a reason anyone should be creating new AjaxError, unless I'm missing a use case?

[benlesh]

To be clear: I'm not blocking this PR. I'm just saying I'm not sure we want to expose the ability to create new AjaxErrors, and I'm totally willing to change my mind.

[benlesh]

Nevermind, I need to learn to read more thoroughly:

Typescript would then complain on projects that use error instanceof AjaxError, as it doesn't identify AjaxError as callable.

[al-mart]

Isn't this a possible solution for both problems ?

class Forgeable {
  static isInstanceFlag = Symbol("isInstanceFlag");

  static [Symbol.hasInstance](obj) {
    return Forgeable.isInstanceFlag in obj;
  }
  
  // @internal 
  constructor() {}
}```
Official MDN 

[voliva]

Isn't this a possible solution for both problems ?

class Forgeable {
  static isInstanceFlag = Symbol("isInstanceFlag");

  static [Symbol.hasInstance](obj) {
    return Forgeable.isInstanceFlag in obj;
  }
  
  // @internal 
  constructor() {}
}```
Official MDN 

That's great to know, and yes, I think it would work now.

For what it's worth, this was added to typescript less than a year ago microsoft/TypeScript#55052, and this issue was raised and PR opened more than 3 years ago.