This document serves to record design decisions to try and share historical context as the project evolves.
who: @nicktomlin
Moving to ESM would mean potentially breaking compatability with folks on modern versions of node who have not switched to ESM and additional overhead in maintaining both systems. Some library authors have decided to simply convert to ESM wholesale.
I would suggest we maintain CJS compat for now, in the hope that there's either better tooling for "dual publishing" or enough momentum behind ESM that publishing a breaking ESM-only version does not cause too much churn for users.
Because it's relatively simple to support interop between ESM and CJS, and the wide footprint.
jest can be a little magical, but it's relatively fast (with 28.x especially), ergonomic, and provides a simple maintenance story over a BYO setup.
I considered mocha and ava (which i've also used and like) but jest struck the best balance between simplicity and feature-set at the moment.
who: @nicktomlin
Typescript publication can be a wacky process and tsup simplifies a lot of this.
who: @dmitryborisov-sm
Since Node.js uses Undici for its built-in fetch functionality, Undici supports HTTP/2 and meets all our requirements. If Undici fails to initialize, the SDK will fall back to the default fetch: HTTP/1.1 in Node 18 and HTTP/2 in browsers. It's also possible to provide a custom fetch function when creating the SDK, so in theory, the SDK could work on older Node versions using libraries like node-fetch.
who: @dmitryborisov-sm
The SDK should follow a layered architecture, with all modifications made in the top layers. This approach enables easy updates to autogenerated code and ensures alignment with API changes, minimizing both effort and risk.