Handle Payload errors with instanceof operator

[MacPiston]

Hi!
In reference to short Discord discussion (https://discord.com/channels/967097582721572934/967097582721572937/1408477234347511909), I'm creating a discussion here.

The problem is related to error classes from payload package. Currently, when handling errors, it is not possible to detect which error is it using well-known instanceof operator. While it may look like this is working initially, after building the app information about error class are lost, no matter if Next config's serverMinification option is disabled or not.

Apparently this is a known issue, but in my opinion it not only significantly affects DX, but can lead to unexpected behavior - especially since this issue stays dormant, unless you build the app and test selected code path here. I've discovered it myself only after tests I've written were not passing on production build for because of not matching expected error messages.

Sample of broken code:

  try {
    await login({<can throw AuthenticationError>});
  } catch (e) {
    if (e instanceof AuthenticationError) {
      // Will never be called on production
      console.log("Works!");
    }
  }

Currently my workaround looks like this:

    if (
      e instanceof Error &&
      (e.constructor.name === AuthenticationError.name ||
        e.constructor.name === LockedAuth.name)
    ) {
      return {
        error: e.message,
      };
    }

While not super-clean, it at least mimics how this would be handled if this bug wasn't here. Also, a codemod will be easy to create after root cause is resolved. One caveat is that it requires serverMinification option to be disabled, because otherwise class names will be lost during build.

I've tried to find out what could be the problem, but I haven't reached any definitive conclusion. I found some similar issues, but they don't match what we have here 100%:

• Unable to issue instanceof Prisma.PrismaClientValidationError on known caught PrismaClientValidationError  prisma/prisma#12128 - similar, but occurs only on development and after HMR takes place
• instanceof is broken when class extends Error type microsoft/TypeScript#13965 - could be the reason, but thread is old and I found in other sources (can't remember where, sorry) that this only occurs when targeting ES5, and afaik current Next version targets newer standard (?)

[MacPiston]

Ok, so few findings after more testing - code is still the same piece from my original post (so the fragment with login) which throws AuthenticationError. AuthenticationError is imported from payload package, and login from @payloadcms/next/auth.

I put two comparisons in catch, one after each other:

1. Object.getPrototypeOf(e) === AuthenticationError.prototype
2. Object.getPrototypeOf(new AuthenticationError()) === AuthenticationError.prototype
   and the results are below.

Dev server (next dev):

1. true
2. true

Production server (next build + next start):

1. false
2. true

In payload repo, result from production server also occurs (for example in test/server-functions/loginFunction) with only difference being that it is a dev script.

So this doesn't quite look like microsoft/TypeScript#13965. I still don't quite understand why this doesn't happen on dev server, but maybe it reads everything from source which results in just one AuthenticationError constructor globally for all code - but again, just a guess, I'm not that knowledgeable.

I wonder whether placing errors in separate package could help? Currently they are a part of payload package, and loginOperation is also a part of it, so they are built together. Maybe if both payload and target app imported from common, prebuilt package? Clearly the issue is the prototype of error instantiated in loginOperation differing from AuthenticationError instantiated in the app itself.