One of the most requested (of which, the requests were always the most impassioned) features was support for EIP-712, signing typed data, which is now available experimentally.

All built-in signers have the _signTypedData method and there is a _TypedDataEncoder class in the utilities for other libraries that wish to have lower level access to the primitives needed to sign typed data or cache intermediate steps.

Once people are happy with the API, the underscores will be dropped, although an alias will be kept for the remainder of v5 so code using it won't break.

In v6, the signTypedData property will become part of the Signer Interface, but that would break backwards compatibility in v5 (to any existing custom sub-classes) so for v5, a class must opt-in by implementing the TypedDataSigner interface.

I would also like to send out a quick thanks to recmo, PhABD and danfinlayfor their assistance with this feature! Thanks!

There is now full testing for React Native! I wanted to mention this and show off some of the things...

The test suite uses NPM to install the react native framework, ethers library and all the necessary CocoaPods to build a React Native App and launch it in an iOS simulator on GitHub actions as part of the Continuous Integration (CI).

One of the more interesting parts I wanted to show off for this solution is the Faux Registry, which I plan to break out at some point as a stand-alone package.

The Faux Registry is a simple node.js Web Server which mimics a normal NPM registry server, except it hijacks any request for a package managed by the monorepo, and serves the local, possibly unpublished version (from the monorepo) as if it were the published metadata and tarball. Any other requests are forwarded along to the actual NPM registry.

This allows the standard NPM workflow to be used when setting up React Native, proceeding how the real world will treat ethers once the version being tested is published.

The ESM build system has undergone some major changes to make life simpler and tree-shaking far more effective for people using ethers in the browser and with bundlers.

There is still some work to be done to make tree-shaking possible for those that use bundlers for node.js distributions, but the majority of users using the ESM builds are browser-based, and it is generally easier for node.js builds to modify their config. Unfortunately, there is no best solution, only various degrees of terrible solutions, but I think this works the best for the widest possible audience.

The new build produce sub-packages with the module field pointed to browser-ready modules, so webpack and rollup.js (and React Native, which uses webpack) require no additional configuration and work out of the box, with full tree-shaking.

The elliptic library is also thinned and bundled into the SigningKey module library, which has traditionally been a pain point for bundlers as it has circular dependencies and thinning it (e.g. pulling out the large pre-generated sep256k1 tables and unused curves and dependencies) requires some somewhat involved code.

• Support for legacy external events with incorrect padding from a Solidity bug; by popular demand from a fleet of Web3.js issues
• The ENSProvider Interface was added to indicate support for Content Hash (like IPFS or Swarm), Text Records (email, website, etc.) and Multi-Chain support (e.g. lookup your Bitcoin address on Ethereum); all providers now support this, including any custom sub-classes (of BaseProvider) you may have written yourself, no additional code required
• Subresource Integrity is now supported for the UMD bundles, and each release's notes includes the necessary code with content hash
• Lerna is no-more; replaced by a handful of local scripts that create the ratsnest of symlinks, this provides a great deal more flexibility, is a lot faster and reduced the number of dev dependencies by over 600, including some with incredibly outdated security issues
• Lots of quality-of-life improvements, input validation and minor bug fixes

• Adding GitHub sponsorship options to see if there is any interest in community funding
• I will be posting an article about v6 which is slated for late-spring/early-summer.
• Research and improve FallbackProvider for calls that are overly wild (e.g. use of now currently causes a lot of quorum issues in the FallbackProvider)
• Use Twitter Polls to get some community feedback on what features or issues people are most interested in me focusing on next
• Research replacing elliptic and bn.js libraries, which will make everyone's bundling life even more simple (this will be part of the poll)