Contributing and Hacking

The ethers.js library is something that I've written out of necessity, and has grown somewhat organically over time.

Many things are the way they are for good (at the time, at least) reasons, but I always welcome criticism, and am completely willing to have my mind changed on things.

Pull requests are always welcome, but please keep a few points in mind:

• Backwards-compatibility-breaking changes will not be accepted; they may be considered for the next major version
• Security is important; adding dependencies require fairly convincing arguments as to why
• The library aims to be lean, so keep an eye on the dist/ethers.min.js file size before and after your changes
• Keep the PR simple and readable; only modify files in the docs.wrm/ and packages/*/src.ts/ folders, as this allows the changes to be easily verified
• Add test cases for both expected and unexpected input
• Any new features need to be supported by me (future issues, documentation, testing, migration), so anything that is overly complicated or specific may not be accepted

In general, please start an issue before beginning a pull request, so we can have a public discussion and figure out the best way to address the problem/feature. :)

Building

The build process for ethers is unfortunatly not super trivial, but I have attempted to make it as straightforward as possible.

It is a mono-repo which attempts to be compatibile with a large number of environments, build tools and platforms, which is why there are a some weird things it must do.

There are several custom scripts in the misc/admin folder to help manage the monorepo. Developers working on contributing to ethers should not generally need to worry about those, since they are wrapped up behind npm run SCRIPT operations.

Making Changes

Once your environment is set up, you should be able to simply start the auto-build feature, and make changes to the TypeScript source.

Creating Browser-Ready Files

To create files for use directly in a browser, the distribution files (located in packages/ethers/dist) need to be built which requires several intermediate builds, scripts and for various rollup scripts to execute.

Testing

Distribution

Most developers should not ever require this step, but for people forking ethers and creating alternates (for example if you have a non-EVM compatible chain but are trying to reuse this package).

This script will rebuild the entire ethers project, compare it against npm, re-write package versions, update internal hashes, re-write various TypeScript files (to get around some ES+TS limitations for Tree Shaking and linking), re-write map files, bundle stripped versions of dependencies and basically just a whole bunch of stuff.

If you use this and get stuck, message me.

Publishing

Again, this should not be necessary for most developers. This step requires using the misc/admin/cmds/config-set script for a number of values, including private keys, NPM session keys, AWS access keys, GitHub API tokens, etc.

The config file is encrypted with about 30 seconds of scrypt password-based key derivation function, so brute-forcing the file is quite expensive.

The config file also contains a plain-text mnemonic. This is a money-pot. Place a tempting amount of ether or Bitcoin on this account and set up an e-mail alert for this account.

If any attacker happens across your encrypted config, they will have instant access to the plain-text mnemonic, so they have the option to immediately steal the ether (i.e. the responsible-disclosure bond).

If you ever see this ether taken, your encrypted file is compromised! Rotate all your AWS keys, NPM session keys, etc. immedately.

@TODO: document all the keys that need to be set for each step

Documentation

The documents are generated using Flatworm documentation generation tool, which was written for the purpose of writing the documentation for ethers.

Style Guide (this section will have much more coming):

• Try to keep lines no longer than around 80 characters
• Avoid inline links in the source; use the externalLinks field in the config.js
• Prefix external links with link-
• Changing an anchor name must be well justified, as it will break all existing links to that section; flatworm will support symlinks in the future
• In general, I aim for consistency; look to similar situations throughout the documentation

Building

To build the documentation, you should first follow the above steps to build the ethers library.

Building the docs will generate several types of output:

• A full set of HTML pages, linking across each other
• A single one-page HTML page with all pages linking to local anchors
• A full set of README.md pages organized to be browsable and linkable in GitHub
• A metadata dump for tool ingestion (still needs more work)
• (@TODO; only half done) The documentation as a LaTeX and generated PDF

Evaluation

When building the documentation, all code samples are run through a JavaScript VM to ensure there are no typos in the example code, as well the exact output of results are injected into the output, so there is no need to keep the results and code in-sync.

However, this can be a bit of a headache when making many small changes, so to build the documentation faster, you can skip the evaluation step, which will inject the code directly.

Previewing Changes

To preview the changes locally, you can use any standard web server and run from the /docs/ folder, or use the built-in web server.

The same caveats as normal web development apply, such flushing browser caches after changing (and re-building) the docs.