Init Readiness Checklist + JavaScript Client Impl

[dOrgJelli]

closes #5
closes #7

NOTE: current failing tests will be fixed when this is released polywrap/javascript-client#8

[namesty]

This looks really good! Could we add a testing requirement? Like, for a feature to be considered "complete" it needs to be tested?

Additionally, it seems to me that a "Data translation" should be included. If we don't implement the Msgpack extension types, some wrappers and plugins will just not work when being invoked with said client

[cbrzn]

the only thing i would change is to put inside wrap-features section the tests defined here: https://github.com/polywrap/javascript-client/tree/origin-dev/packages/client/src/__tests__/core/wrap-features - or at least; only env and interface-invoke. also, instead of creating a section named wrap test harness, I would name this with type support (not sure about this name tho, open to suggestions); here, we would test what lives inside of the harness

[cbrzn]

also, should we use rust instead of ts? i think it would make sense to use rust for the "runner" of test cases? not a blocker for this pr tho, but just wondering 😋

[dOrgJelli]

This looks really good! Could we add a testing requirement? Like, for a feature to be considered "complete" it needs to be tested?

Can you give an example of this? Not exactly sure what you mean here.

Additionally, it seems to me that a "Data translation" should be included. If we don't implement the Msgpack extension types, some wrappers and plugins will just not work when being invoked with said client

Yes definitely, let me explain how I've done this. Originally I had granular msgpack testing within the checklist (see here), but I removed it as I felt it was too granular and concerned itself with too many wrap-side implementation details.

Instead these MsgPack cases can be covered using the existing wrap-test-harness test cases. I've added a few of them (Map, JSON, BigInt, BigNumber), and we can certainly add the others that are missing (UInt, Int, String, Bytes, etc).

[dOrgJelli]

the only thing i would change is to put inside wrap-features section the tests defined here: https://github.com/polywrap/javascript-client/tree/origin-dev/packages/client/src/__tests__/core/wrap-features - or at least; only env and interface-invoke. also, instead of creating a section named wrap test harness, I would name this with type support (not sure about this name tho, open to suggestions); here, we would test what lives inside of the harness

Nice I really like these suggestions, will make some quick changes!

[dOrgJelli]

also, should we use rust instead of ts? i think it would make sense to use rust for the "runner" of test cases? not a blocker for this pr tho, but just wondering yum

I used TS for the verify/ CLI because it was super simple to write, as I really just needed a simple script to run. I don't know if there is a need to writing it with Rust, but I'm open to suggestions.

[dOrgJelli]

@namesty @cbrzn your comments should be addressed, would appreciate a re-review.

[cbrzn]

also, should we use rust instead of ts? i think it would make sense to use rust for the "runner" of test cases? not a blocker for this pr tho, but just wondering yum

I used TS for the verify/ CLI because it was super simple to write, as I really just needed a simple script to run. I don't know if there is a need to writing it with Rust, but I'm open to suggestions.

nope, there's no need I think; but since we want to have most of our stack in rust, why not start doing this w/rust? like pwr cli or the wrap test harness - no strong opinion on this tho 😄

[namesty]

This looks really good! Could we add a testing requirement? Like, for a feature to be considered "complete" it needs to be tested?

Can you give an example of this? Not exactly sure what you mean here.

Yeah, you're already doing it with your src/features directory.

Additionally, it seems to me that a "Data translation" should be included. If we don't implement the Msgpack extension types, some wrappers and plugins will just not work when being invoked with said client

Yes definitely, let me explain how I've done this. Originally I had granular msgpack testing within the checklist (see here), but I removed it as I felt it was too granular and concerned itself with too many wrap-side implementation details.

Instead these MsgPack cases can be covered using the existing wrap-test-harness test cases. I've added a few of them (Map, JSON, BigInt, BigNumber), and we can certainly add the others that are missing (UInt, Int, String, Bytes, etc).

I agree :D