Skip to content

Latest commit

 

History

History
249 lines (162 loc) · 11.9 KB

CHANGELOG.md

File metadata and controls

249 lines (162 loc) · 11.9 KB

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

Changed

  • Bump @metamask/utils from ^10.0.0 to ^11.0.1 (#5080)
  • Bump @metamask/rpc-errors from ^7.0.0 to ^7.0.2 (#5080)

Changed

  • Bump @metamask/utils from ^9.1.0 to ^10.0.0 (#4831)

Fixed

  • BREAKING: Bump @metamask/rpc-errors from ^6.3.1 to ^7.0.0 (#4773)
    • This modifies the top-level error message for serialized internal JSON-RPC errors to include the actual error message, instead of the generic Internal JSON-RPC Error. string.

Changed

  • Bump TypeScript from ~5.0.4 to ~5.2.2 (#4576, #4584)

Fixed

  • Produce and export ESM-compatible TypeScript type declaration files in addition to CommonJS-compatible declaration files (#4648)
    • Previously, this package shipped with only one variant of type declaration files, and these files were only CommonJS-compatible, and the exports field in package.json linked to these files. This is an anti-pattern and was rightfully flagged by the "Are the Types Wrong?" tool as "masquerading as CJS". All of the ATTW checks now pass.
  • Remove chunk files (#4648).
    • Previously, the build tool we used to generate JavaScript files extracted common code to "chunk" files. While this was intended to make this package more tree-shakeable, it also made debugging more difficult for our development teams. These chunk files are no longer present.

Changed

  • Bump TypeScript version to ~5.0.4 and set moduleResolution option to Node16 (#3645)
  • Bump @metamask/utils from ^9.0.0 to ^9.1.0 (#4529)

Changed

  • Bump @metamask/rpc-errors from 6.2.1 to ^6.3.1 (#4516)
  • Bump @metamask/utils from ^8.3.0 to ^9.0.0 (#4516)

Changed

  • BREAKING: Bump minimum Node version to 18.18 (#3611)

Changed

  • Widen the error parameter of JsonRpcEngineReturnHandler, JsonRpcEngineEndCallback function types from JsonRpcEngineCallbackError to unknown (#3906)
  • Narrow the function parameters req, callback of the last overload of the handle method of the JsonRpcEngine class (#3906)
    • This applies to the overload with two function parameters, one required and one optional, and no generic parameters.
    • req is narrowed from unknown to (JsonRpcRequest | JsonRpcNotification)[] | JsonRpcRequest | JsonRpcNotification.
    • callback is narrowed from any to (error: unknown, response: never) => void.
  • Bump TypeScript version to ~4.9.5 (#4084)

Fixed

  • Fix types field in package.json (#4047)

Added

  • BREAKING: Add ESM build (#3998)
    • It's no longer possible to import files from ./dist directly.

Changed

  • Bump @metamask/rpc-errors to ^6.2.1 (#3954)

Changed

  • Bump @metamask/utils to ^8.3.0 (#3769)

Changed

  • There are no consumer-facing changes to this package. This version is a part of a synchronized release across all packages in our monorepo.

Added

  • Migrate @metamask/json-rpc-engine into the core monorepo (#1895)

Changed

  • Bump @metamask/utils from ^8.1.0 to ^8.2.0 (#1895)
  • Bump @metamask/rpc-errors from ^6.0.0 to ^6.1.0 (#1882)
  • Bump @metamask/auto-changelog from 3.4.2 to 3.4.3 (#1997)

Added

  • Applied eslint rules from core monorepo (#172)

Changed

  • Bumped @metamask/utils from ^5.0.2 to ^8.1.0 #158 (#162)
  • Bumped @metamask/rpc-errors from ^5.0.0 to ^6.0.0 (#162)

Changed

  • Bumped @metamask/safe-event-emitter from ^2.0.0 to ^3.0.0 (#148)
  • Bumped @metamask/utils from ^5.0.1 to ^5.0.2 (#151)

Fixed

  • Fixed handling of empty batch array in requests (#153)

Added

  • Added JSON-RPC notification handling (#104)
  • Added destroy method (#106)

Changed

  • BREAKING: Require a minimum Node version of 16 (#139)
  • BREAKING: Use @metamask/utils types (#105)
    • The JSON-RPC engine and all middleware now use @metamask/utils JSON-RPC types
  • (BREAKING) Return a null instead of undefined response id for malformed request objects (#91)
    • This is very unlikely to be breaking in practice, but the behavior could have been relied on.
  • Change package name to @metamask/json-rpc-engine (#139)
  • Use @metamask/rpc-errors (#138)

6.1.0 - 2020-11-20

Added

  • Add PendingJsonRpcResponse interface for use in middleware (#75)

Changed

  • Use async/await and try/catch instead of Promise methods everywhere (#74)
    • Consumers may notice improved stack traces on certain platforms.

6.0.0 - 2020-11-19

Added

  • Add docstrings for public JsonRpcEngine methods (#70)

Changed

  • (BREAKING) Refactor exports (#69)
    • All exports are now named, and available via the package entry point.
    • All default exports have been removed.
  • (BREAKING) Convert asMiddleware to instance method (#69)
    • The asMiddleware export has been removed.
  • (BREAKING) Add runtime typechecks to JsonRpcEngine.handle(), and error responses if they fail (#70)
    • Requests will now error if:
      • The request is not a plain object, or if the method property is not a string. Empty strings are allowed.
      • A next middleware callback is called with a truthy, non-function parameter.
  • Migrate to TypeScript (#69)
  • Hopefully improve stack traces by removing uses of Promise.then and .catch internally (#70)
  • Make some internal JsonRpcEngine methods static (#71)

5.4.0 - 2020-11-07

Changed

  • Make the TypeScript types not terrible (#66, #67)

5.3.0 - 2020-07-30

Changed

  • Response object errors no longer include a stack property

5.2.0 - 2020-07-24

Added

  • Promise signatures for engine.handle (#55)
    • So, in addition to engine.handle(request, callback), you can do e.g. await engine.handle(request).

Changed

  • Remove async and promise-to-callback dependencies
    • These dependencies were used internally for middleware flow control. They have been replaced with Promises and native async/await, which means that some operations are no longer eagerly executed. This change may affect consumers that depend on the eager execution of middleware during request processing, outside of middleware functions and request handlers.
      • In general, it is a bad practice to work with state that depends on middleware execution, while the middleware are executing.