Development & release guidelines for noble (https://paulmillr.com/noble), scure and other packages.
Before a release, integration tests should be ran. For example, if curves depend on hashes, they should install latest commit from github and try to run tests with it.
Release order is as follows:
- noble-hashes, noble-ciphers, scure-base
- noble-curves
- scure-bip32, scure-bip39
- micro-packed, scure-btc-signer
- ethereum-cryptography
After that, 6. pull requests to consumers (such as ethereumjs-monorepo) can also be done.
- Don't use bigint literals: instead of
123n
, useBigInt(123)
orBigInt('123')
- For compatibility with React Native and others
- Don't use array destruction, such as
let [a, b] = arr
- It overloads GC when used often, because it calls iterator protocol
- Object destruction
{a, b} = obj
is fine
- Minimize
for-of
- Also uses iterator protocol, sometimes slow
- Minimize backtick quotes
- Unfriendly to minifiers, sometimes even unsupported in subtle ways
- Don't use
\n
in strings: preferString.fromCharCode(10)
- Unfriendly to minifiers
- Typescript and prettier updates should be limited to once per 3-6 months
- Their version diffs should be sanity-checked
- Helper packages are used to simplify development
- paulmillr/jsbt is used to build files
- micro-should is tiny 300-line testing framework
- micro-bmark is tiny benchmarking framework
Some code is duplicated between packages, because it's better than adding an additional dependency.
Every time a method is changed, it should also be changed in other places.
hexToBytes
,bytesToHex
,concatBytes
,isBytes
/abytes
are identical within:- noble curves, ciphers, hashes
- noble secp256k1, ed25519 (vars renamed for compactness)
- scure-base, micro-packed
- Tests for
hexToBytes
,bytesToHex
,concatBytes
must be present within all those packages
- hashes should run
test:dos
andtest:big
- curves should adjust fast-check
NUM_RUNS
when ran on CI server
- Fuzzing documentation
- CI server set-up documentation
- minified file build & upload (update JSBT)
New CI tasks:
- Calculate coverage. Can be done by switching from micro-should to jest
- Compare NPM code to GitHub
- Scan NPM for malware
- Check for performance regressions, compare with previous commits / releases