flex-development / exceptions Goto Github PK

Description

Using @flex-development/[email protected] in a Next.js project yields a DeprecationWarning:

info  - Creating an optimized production build...
(node:13935) [DEP0128] DeprecationWarning: Invalid 'main' field in '/Users/lex/Projects/FLDV/TEMPLATES/unistack/apps/web/node_modules/@flex-development/exceptions/package.json' of 'dist/index.js'. Please either fix that or report it to the module author
(Use `node --trace-deprecation ...` to show where the warning was created)

Steps to reproduce

1. Create a Next.js project using [email protected]
2. Install @flex-development/[email protected]
3. Run next build
4. See error

Expected behavior

A DeprecationWarning should not be thrown when using @flex-development/[email protected].

Relevant screenshots

N/A

Environment

• Node Version: v16.6.0
• OS: macOS v11.3.1
• Package Manager: [email protected]
• Package version(s): @flex-development/[email protected]
• Browser: N/A

Possible solution

The create-dist-package-json script used in @flex-development/exceptions contains the logic to update the package main field, but it seems it didn't work properly for v2.0.1. Additionally, since first releasing this project, our organization's package build, publish, and release workflows have undergone major changes. Those updates should be implemented in this repository.

Additional context

N/A

Describe the ideal solution or feature request

Node.js 15 updates the JavaScript engine to V8 8.6, which introduces the AggregateError class. As explained in the MDN docs, the AggregateError class groups several errors together:

The AggregateError object represents an error when several errors need to be wrapped in a single error. It is thrown when
multiple errors need to be reported by an operation

Despite the current type definition for Exception#errors allowing for more than array types, a more appropriate superclass for Exception would be AggregateError seeing that the property name indicates a group of errors.

This update would introduce several changes:

• Refactor data transfer objects, interfaces, and type definitions

  /**
   * `Exception` data transfer object.
   *
   * @template T - Aggregated error type
   */
  export interface ExceptionDataDTO<T extends any = any> { ... }

  /**
   * JSON representation of an `Exception`.
   *
   * @template T - Aggregated error type
   */
  export interface ExceptionJSON<T extends any = any> { ... }

  /**
   * Exception#errors` shape.
   *
   * @template T - Aggregated error type
   */
  export type ExceptionErrors<T extends any = any> = Array<T>

• Convert Exception into a generic and extend AggregateError

  /**
   * @template T - Aggregated error type
   *
   * @extends {AggregateError}
   */
  class Exception<T extends any = any> extends AggregateError { ... }

Note:

• Refactoring ExceptionErrors is a breaking change
• Node.js users must be using at least Node.js 15
• Some users may need to polyfill the AggregateError class

Additionally, we should take this opportunity to enforce (mostly) proper Error subclassing. Aside from the class naming rule, all rules defined by eslint-plugin-unicorn rule unicorn/custom-error-definition should be followed. This also requires a breaking change - we need to rename ExceptionName as well as update all associated naming logic.

Impact, usage, and difficulty

How does this tie into our current product?

The original intention for this package was to implement a consistent Error subclass API as well as provide stricter type definitions than the @feathers/errors library. This update makes existing type definitions stricter and subsequently improves consistency when working with Exception class objects. If this request is implemented, users no longer have to check if Exception#errors is an array, object, or string. The property will always be an array, and therefore users can always use Array APIs when interfacing with Exception#errors property.