Sentry-javascript: ERROR: la versión 3.23.2 provocó un cambio en los mensajes de excepción debido a un serializador de excepciones sin errores

Ese parece ser un comportamiento muy extraño de los módulos JS.

Cuando usas:

import ExtendableError from 'es6-error'

class CustomError extends ExtendableError {
  constructor(code, message) {
    super(message)
    this.name ='CustomError'
    this.code = code
  }
}

function isPlainObject(what) {
  return Object.prototype.toString.call(what) === '[object Object]';
}

function isError(value) {
  switch ({}.toString.call(value)) {
    case '[object Error]':
      return true;
    case '[object Exception]':
      return true;
    case '[object DOMException]':
      return true;
    default:
      return value instanceof Error;
  }
}

function isErrorEvent(value) {
  return Object.prototype.toString.call(value) === '[object ErrorEvent]';
}

var ex = new CustomError('code123', 'not working');

console.log('isPlainObject:', isPlainObject(ex))
console.log('isError:', isError(ex))
console.log('isErrorEvent:', isErrorEvent(ex))

Informará incorrectamente true/true/false .

Sin embargo, cuando sustituyas la instrucción import con el código mismo

class ExtendableError extends Error {
  constructor(message = '') {
    super(message);

    // extending Error is weird and does not propagate `message`
    Object.defineProperty(this, 'message', {
      configurable: true,
      enumerable : false,
      value : message,
      writable : true,
    });

    Object.defineProperty(this, 'name', {
      configurable: true,
      enumerable : false,
      value : this.constructor.name,
      writable : true,
    });

    if (Error.hasOwnProperty('captureStackTrace')) {
      Error.captureStackTrace(this, this.constructor);
      return;
    }

    Object.defineProperty(this, 'stack', {
      configurable: true,
      enumerable : false,
      value : (new Error(message)).stack,
      writable : true,
    });
  }
}

informará correctamente false/true/false .

Intentaré depurar por qué es así y, si no puedo averiguarlo, cambiaremos los cheques para pasar por isError primero.

@zivl Cuando lo prueba localmente y crea su propio archivo custom-error.js con ese código y lo importa como un módulo, funciona correctamente.

El problema es que esta biblioteca no exporta su código "tal cual", sino que lo precompila usando Babel.

Así que termina siendo un error "algo" pero no realmente. Es un objeto simple que hereda propiedades específicas y tiene un prototype establecido en el mismo Error .

Desafortunadamente, no hay otra forma de evitar esto que no sea cambiar el orden de verificación, ya que es como un "error de Schrödinger". Es y no es un Error al mismo tiempo.

@zivl lanzado en 3.23.3 . ¡Gracias por el informe!