Add new TypeScript bindgen

[RareSecond]

First pass at generating a new .ts file that can be used as the main entrypoint for the updated TypeScript SDK.

This current iteration works perfectly fine for fire-and-forget actions. However, once I start incorporating statefulness into the setup, this file may need some changing. But wanted to get this in already, so that future changes can be more focused on specific features!

Can be tested by running sozo build --typescript-v2

[codecov]

Codecov Report

Attention: Patch coverage is 99.45554% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 69.14%. Comparing base (fc5ad79) to head (3494fde).
Report is 27 commits behind head on main.

Files	Patch %	Lines
...ates/dojo-bindgen/src/plugins/typescript_v2/mod.rs	99.62%	2 Missing ⚠️
bin/sozo/src/commands/build.rs	90.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1783      +/-   ##
==========================================
+ Coverage   67.43%   69.14%   +1.71%     
==========================================
  Files         305      308       +3     
  Lines       33521    34612    +1091     
==========================================
+ Hits        22604    23934    +1330     
+ Misses      10917    10678     -239     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[glihm]

@RareSecond great first pass here!
Some minor comment on the go for now.

I'm wondering how we can test that effectively. Is the generated JS file something we can run easily somehow to at least verify there's no errors?
Because doing string comparisons can be a solution, but we may think of something better to ensure more robust testing on the code generation.

For the test failing for the format, you have a script into the repo scripts/rust_fmt.sh. You can run it to verify locally. And if you want auto formatting, run the same command that's inside the script and remove the --check.

[RareSecond]

I'm wondering how we can test that effectively. Is the generated JS file something we can run easily somehow to at least verify there's no errors? Because doing string comparisons can be a solution, but we may think of something better to ensure more robust testing on the code generation.

Hmm what about saving a snapshot of the fully generated file and testing against that? It should always output the exact same content for the same input.

[glihm]

I'm wondering how we can test that effectively. Is the generated JS file something we can run easily somehow to at least verify there's no errors? Because doing string comparisons can be a solution, but we may think of something better to ensure more robust testing on the code generation.

Hmm what about saving a snapshot of the fully generated file and testing against that? It should always output the exact same content for the same input.

Yep, sounds a good approach. This is what we have for dojo-lang, we run a command like:

CAIRO_FIX=1 cargo test ...

and it counts as a generation run where the output will be considered as the truth for the other test runs without with CAIRO_FIX.

However, I was thinking about something more functional, ensuring at least the JS code generated is correct and "compiles"/"can be interpreted correctly".
But let's do a first pass as you mentioned, testing that the output is as expected, and for now let's have a file that you've tested on your end and you know it works in JS.

WDYT @RareSecond?

[RareSecond]

Sounds good! However, I'll need some guidelines on how to best approach this testing. Because I don't know how stuff is currently mocked in the repo, i.e. how do I ensure the function is called with the correct testing parameters.

[glihm]

@RareSecond I've let some comments about testing and answering some questions. Let me know if you have doubt on this or if it's unclear, we can catch up anytime. 👍

[glihm]

@RareSecond great work on this!
As we've mentioned, as this plugin will be enhanced soon we will apply more tests on top of these modifications. 👍

As dojo-js is widely used, we should have at some functional test to ensure we're generating valid javascript. Let's discuss that at the next iteration.

The examples folder will soon contain more examples with some edge cases like several contracts with same name etc.. this will also be a good test to see how we handle such ones.