nodejs or typescript, or even both

[davidkhala]

It has been a difficult problem for me that use nodejs or typescript, or both to write a SDK for community usage.

• fabric-sdk-node was pure nodejs with typescript definition binding
• Personally, I prefer not to use a compilation syntax candy with additional layer to consider setup and version map.
• Type is what everyone wants, including me. In nodejs, aligning with classic fabric-sdk-node code style, I use jsDoc to define neccesary type restriction, and leverage IDE to kindly reminds user of type. This will be more strict in Typescript.
• Think twice to support extensibility, not matter in nodejs or TS. And TS allows less syntax freedom.
• khala-fabric-admin, written in pure nodejs, can be contributed to TWGC out-of-box as first implementation. It helped community as reference for discussion, evaluation, and proof of viablity of classic SDK extensibility. And this value points can also be applied here.

[bestbeforetoday]

TypeScript compiles to plain JavaScript so can be consumed just as easily by applications developed in TypeScript or plain JavaScript. What it does give you is:

1. 100% correct type definitions for TypeScript users, for free. Hand-crafting and maintaining type definitions for JavaScript code is incredibly time-consuming and error-prone.
2. Correct typing in your API documentation, for free. Hand-crafting and maintaining the types in JSDoc is time-consuming and error-prone.
3. Better tooling support (easier to navigate using IDEs such as VS Code) and better automated code correctness checking (TS compiler and linter).

Certainly you can use plain JavaScript and make everything work. However, my experience is that, if you are aiming to provide typing, it is actually less work and much more reliable to use TypeScript to start with.

[davidkhala]

TypeScript compiles to plain JavaScript so can be consumed just as easily by applications developed in TypeScript or plain JavaScript. What it does give you is:

1. 100% correct type definitions for TypeScript users, for free. Hand-crafting and maintaining type definitions for JavaScript code is incredibly time-consuming and error-prone.
2. Correct typing in your API documentation, for free. Hand-crafting and maintaining the types in JSDoc is time-consuming and error-prone.
3. Better tooling support (easier to navigate using IDEs such as VS Code) and better automated code correctness checking (TS compiler and linter).

Certainly you can use plain JavaScript and make everything work. However, my experience is that, if you are aiming to provide typing, it is actually less work and much more reliable to use TypeScript to start with.

Agree and more after I found the new generated schema in new fabric-protos is fully TS friendly!

[davidkhala]

supplement

• For the mocha framekwork, there is not simple way to configure it gracefully with typescript beside using ts-mocha

Then it introduces a sub-discussion, which test-framework should we used for node/ts implementation?

[bestbeforetoday]

I ended up switching from a combination of mocha, chai, sinon and Istanbul/nyc, to just using Jest. It provides test runner, assertions, stubs/mocks and coverage all in one package so seems a bit more consistent and less work to maintain. See fabric-gateway project for how I am using it. Other people will likely have their own (perfectly valid) experiences and preferences though!

[davidkhala]

Although jest claims it does't require configuration. But it does need more than mocha. Fortunately, not too much configuration items required so far.

Eliminating this blockage, I am ready to use(and using) TS the single source syntax.