The package humanize-string uses an old version of the package decamelize. Probably because of breaking changes, humanize-string uses [email protected], while the newest version is 5.0.0.

This is a problem because the old version of decamelize uses xregexp, which has issues when being transpiled for IE11, i.e. it produces an infinite loop. decamelize stopped using xregexp in around version 4.0.0

We don't usually change things to support IE11 and I hate that that is the reason why I am proposing this, but this change has other good side-effects. humanize-string does much more than we need. We use it to produce readable strings from error names, which is a pretty tiny subset of what humanize-string can do and which we can easily do ourselves.

So we should remove humanize-string and replicate it's behavior ourselves.

Mainly for testing purposes but also surely for other use cases I want to add a unwrapErrorOrThrow function to Results, so that in cases where we know that something fails we can access the error directly without having to write an if statement.

This new property might conflict with our cause propery on CustomError. Once nodejs updates to v8 9.3 we need to check whether this is a problem.

What is this issue about?

At the moment you can set a type for data attribute of a custom error, but it will still always be optional. This seems like an unnecessary restriction. By default the type of data is any, so therefore optional anyway and if you want it to be optional for the custom type you provide, you could just write it explicitly like t | undefined. So I think we can safely make it the data attribute required.

Once we migrate to TypeScript (this primarily depends on migrating roboter to TypeScript), we can use this implementation:

import humanizeString from 'humanize-string';

export interface ICustomError extends Error {
  name: string;
  code: string;
  message: string;
  cause?: Error;
}

type ErrorConstructors<T> = {
  [key in keyof T]: new(message?: string, cause?: Error) => ICustomError
};

const defekt = function <T extends {
  [ key: string ]: { code?: string };
}> (errorDefinitions: T): ErrorConstructors<T> {
  const errors: Partial<ErrorConstructors<T>> = {};

  /* eslint-disable guard-for-in */
  for (const errorName in errorDefinitions) {
    const errorDefinition = errorDefinitions[errorName];

    if (!errorDefinition) {
      continue;
    }

    const { code = `E${errorName.toUpperCase()}` } = errorDefinition;

    errors[errorName] = class extends Error implements ICustomError {
      public name: string;

      public code: string;

      public message: string;

      public cause?: Error;

      /* eslint-disable no-loop-func */
      public constructor (message = `${humanizeString(errorName)}.`, cause?: Error) {
        super();

        this.name = errorName;
        this.code = code;
        this.message = message;
        this.cause = cause;
      }
      /* eslint-enable no-loop-func */
    };
  }
  /* eslint-enable guard-for-in */

  return errors as ErrorConstructors<T>;
};

export default defekt;

After we define errors with defekt, we create error instances by using an ErrorConstructor. This is our own type and not to be confused with node's ErrorConstructor. Sometimes, we want to create errors dynamically, and for that we want to pass the ErrorConstructors around. At the moment, our own type is not exported, so when we pass the constructors generated by defekt around, they default to the built-in ErrorConstructor type, widening the type obtained by invoking the constructor from CustomError to Error.

I think we should export our own ErrorConstructor as well.