feat(rgbpp-sdk-service): support generate_rgbpp_transfer_all_txs API

[ShookLyngs]

Changes

• Support generate_rgbpp_transfer_all_txs in the rgbpp-sdk-service for batch transferring of RGB++ xUDT assets, previously implemented at feat(rgbpp): support for batch transferring of RGBPP XUDT assets #270
• Refactor toSnakeCase() and toCamelCase() to provide clearer return types
• Fix "module": "NodeNext" related import path issues
  • The src/* path shortcut does not work
  • Relative imports must end with .js
• Add rgbpp-sdk-service tests to the test.yml workflow

Found issues

Case transformation issue

The toSnakeCase() util transforms all object keys to snake_case, e.g. snakeCase to snake_case. But when transforming the TransactionGroupSummary object, an issue was found that if the object key is a hex string, it will also be transformed as snake_case, e.g. 0xe1e to 0_xe_1e. This is unexpected.

In the current implementation of the generate_rgbpp_transfer_all_txs API, I wrapped the result with an util ensureSafeJson(), which detects if the object key starts with 0_x, then all underscore marks in the key will be removed, reverting it to a regular hex string, e.g. 0_xe_1e to 0xe1e.

// XXX: Remove underscores from hex strings due to toSnakeCase() transformation issue
if (key.startsWith('0_x')) {
  key = key.replaceAll('_', '');
}

BigInt to String issue

The requests in the rgbpp-sdk-service returns JSON as response. An JSON-related issue was found that it doesn't serialize BIgInt values. When an object that contains such type of value is passed to JSON.stringify(), the function throws an error:

TypeError: Do not know how to serialize a BigInt

Currently, I just transform all BIgInt values to hex strings:

// XXX: Convert BigInt to hex string for JSON.stringify() compatibility
if (typeof value === 'bigint') {
  obj[key] = `0x${value.toString(16)}`;
} else {
  obj[key] = value;
}

[duanyytop]

an issue was found that if the object key is a hex string, it will also be transformed as snake_case, e.g. 0xe1e to 0_xe_1e. This is unexpected.

Why does a key with 0x-hex-string appear?

[duanyytop]

Relative imports must end with .js

May I ask why the .js suffix is needed? It worked fine in my local computer without type: module and .js suffix.

[duanyytop]

We should avoid BigInt data in the parameter instead of converting BigInt to hex-string in the JSON stringify function.

It is recommended not to introduce unnecessary complexity, as it may lead to potential bugs.

[Flouse]

https://github.com/search?q=repo%3Ackb-cell%2Frgbpp-sdk%20%3A%20bigint%3B&type=code shows that bigint has been used in packages/ckb/src/types.
So, maybe this ensureSafeJson function is necessary in the current stage？

[duanyytop]

Yes. However, not all types will be converted to JSON strings. If we add the ensureSafeJson function, we should add tests to ensure it works fine.

[ShookLyngs]

Sure, I can add some tests for it. Bold question: Is it possible to refactor all usages of the native bigint to use BI and hex strings instead? Would this be considered a breaking change, or is it acceptable to refactor it partially?

[duanyytop]

Only affects JSON stringify for BigInt.

So I don't think it is necessary to refactor.

[ShookLyngs]

Updated at 27bb01e; added tests for the util functions, and the test.yml workflow now includes the tests for rgbpp-sdk-service. Another change is that I replaced jest with vitest because jest was buggy when bundling/compiling the source code in ESM mode.

[duanyytop]

Maybe we can use this package https://www.npmjs.com/package/camelcase-keys to convert data to snake case with deep mode and it is more simple.

[ShookLyngs]

I think you mean: https://github.com/bendrucker/snakecase-keys

This is actually a good idea, not because the type the package provides, but because it provides a exclude option for excluding strings from being transformed. If everything goes well, this package should help resolve the 0xe1e to 0_xe_1e issue in another way. I'll give it a try.

[duanyytop]

Sorry, https://github.com/bendrucker/snakecase-keys is right.

[ShookLyngs]

Updated at 27bb01e; both toSnakeCase() and toCamelCase() have been reimplemented using snakecase-keys and camelcase-keys, for the exclude feature they provide.

[Flouse]

LGTM