Ahoy!
Wow... Three months have just flown by and it's already time for Round 9 of the GitCoin Grants, which I'm still appreciating each round as little nudge and a bit of pressure to release each quarterly update.
Again, I cannot express enough how thankful I am to everyone who contributes. Not just to ethers, but to all the projects that are out there, making a difference to myself, fellow developers and the ecosystem at large.
High-five yourself, and keep on begin excellent to one another. Party on!
I've been trying to get as many issues triaged and pull requests merged or closed before releasing a public beta for v6.
Once I make the fork, maintenance become twice as time consuming as patches need to be made against both branches, so it is best to start with as few outstanding issues as possible.
So, over the next few weeks I'll be more aggressive resolving issues (closing stale issues, marking for future releases, etc.) but also migrating many of the issues to GitHub's new Discussion feature. Nearly half of the currently open issues are actually discussions anyways, which will leave issues open for just bugs (currently zero) and feature requests.
The Berlin hard fork has a few EIPs in it that snuck up on me and are going live far faster than I expected.
So, the utils.parseTransaction and utils.serializeTransaction will soon have full EIP-2718 (Typed Transaction Envelopes) and EIP-2930 (Optional Access Lists) so keeping your applications up to date with the latest network changes should just be a matter of updating your version of ethers.
This does require an interface change, such as adding a type and accessListfield, which will be optional parameters, so this should be backwards compatible.
For the most part, I expect this change to have very little impact on most developers as untyped transactions are still valid, so older versions of ethers will continue to work, but you will need to update ethers if you wish to send transactions that use the optional access lists or get the type property from provider.getTransaction(hash).
If anyone does have any issues though, I'll be available to help out with any migration woes.
Most of my time over the last two months has gone into v6, refactoring, rewriting and experimenting with some TypeScript non-sense I've had rattling around in my head. I just thought I'd share a few bullet points that are on the horizon.
When I started using TypeScript for v4, it was a brand new language to me, and I was still learning many of the finer intricacies, best practices and how other tools interacted with it and the code it generated.
Additionally, TypeScript has been an evolving language, and with each version, they seem to have been reading my mind, and addressing many of my early complaints.
Now that I'm a (little?) older and little wiser for the wear, there are a lot of areas I am focussing on to help make things "pop" a bit more with the typing system and fall into place.
Currently v5 supports any ES3 (ish) environment. While this means it is likely to run more of less fine on that laptop in your closet from 2009, it also means a lot of newer features have not been able to be used, even internally.
In v6, ethers will require an ES2016 (aka ES5) environment.
This will allow ethers to use private fields (transpiled via WeakMaps), which means private variables will truely be private, which improves safety, security and performance.
It also opens up a world of useful features, such as Proxies, which make for a much smoother meta-class experience, which is the basis for the Contract APIs.
This also means that node.js version 8 will no longer be supported, but I suspect this does not impact very many people.
Contracts will be one of the areas to see the most significant changes. They will use the Proxy API, which means a lot of things become possible that weren't possible before.
For example, looking up a Contract method can be done with non-normalized signatures, so both foo(address) and foo(address bar) will work. Also, any warnings for ambiguous ABI methods can be deferred and only emitted if the offending methods are used.
I'm also planning an explicit (optional) Type Object, which will allow calling overloaded methods, without having to specify them by their signature at all, so contract.foo(Type.uint160(b) will know how to pick the right method if there are mulitple foo methods.
The buckets will also be going away (e.g. contract.staticCall.foo, contract.populateTransaction.foo) and the order will be moved around a bit (e.g. contract.foo.staticCall and contract.foo.populateTransaction) while the base method will still perform the default operations (e.g. contract.foo()). They were originally in place to more closely match how the Interface works so they could be iterated through, but the Interface is no longer a meta-class, so it is easier to inspect in general.
More objects will be proper classes, instead of basic objects with a plethora of properties.
A Transaction object can be created from a bunch of properties, or serialized transaction data (signed or unsigned), and depending on its type and what properties it has, can have other properties computed. There is also a mutable Transaction state which allows for easier incremental creation.
Contract objects and Signer objects will both implement the Addressableinterface, which means they can be used anywhere an address can, such as the to field in a transaction, or as the address passed into the Provider getStorageAt method.
The Web API is getting a major overhaul too, making it easier to interact with a larger variety of backends, including requests which need to be individually signed, similar to AWS requests.
I've been playing around with some alternatives to the current dependencies to reduce the number of dependant packages over all and select more compatible and friendly options.
Ethers currently sits at 5 dependencies (6 for node.js, as it requires a WebSocket library) but 3 of those dependencies have historically been a headache for bundlers, and are tightly coupled to each other, so the plan is to replace elliptic, BN.js and hash.js with something lean and bundler-friendly.
For the sake of mystique and intrigue, I'll just say "more on that later..." ;)