fix(bindings): building package

[MCozhusheck]

Description

Tari.js is depending on this package but after inspecting it's dependencies I found issues with bindings package like incorrect package.json deceleration and project structure.

Motivation and Context

This PR is necessary to also fix Tari.js which throws errors in others project depending on it with error message that Tari.js is missing types declarations.

How Has This Been Tested?

Locally build bindings and imported it to local Tari.js and after that imported Tari.js to the Tari-Universe and checked if application was working as expected.

What process can a PR reviewer use to test or verify this change?

Build it locally with npm run build command and use it as dependency in other projects.

Breaking Changes

• None
• Requires data directory to be deleted
• Other - Please specify

Some types have changed their name to distinguish from each other and everything now it's exported directly from main file index.ts so imports like

import type { ComponentAddressOrName } from "@tari-project/typescript-bindings/wallet-daemon-client";

should be now:

import type { ComponentAddressOrName } from "@tari-project/typescript-bindings";

[github-actions]

Test Results (CI)

556 tests  ±0   556 ✅ ±0   1h 42m 15s ⏱️ + 9m 9s
 65 suites ±0     0 💤 ±0 
  2 files   ±0     0 ❌ ±0 

Results for commit 1c71647. ± Comparison against base commit 001f797.

This pull request removes 36 and adds 36 tests. Note that renamed tests count towards both.

tari_indexer_client ‑ types::export_bindings_addpeerrequest
tari_indexer_client ‑ types::export_bindings_addpeerresponse
tari_indexer_client ‑ types::export_bindings_connection
tari_indexer_client ‑ types::export_bindings_connectiondirection
tari_indexer_client ‑ types::export_bindings_getallvnsrequest
tari_indexer_client ‑ types::export_bindings_getallvnsresponse
tari_indexer_client ‑ types::export_bindings_getcommsstatsresponse
tari_indexer_client ‑ types::export_bindings_getconnectionsresponse
tari_indexer_client ‑ types::export_bindings_getepochmanagerstatsresponse
tari_indexer_client ‑ types::export_bindings_getidentityresponse
…

tari_indexer_client ‑ types::export_bindings_indexeraddpeerrequest
tari_indexer_client ‑ types::export_bindings_indexeraddpeerresponse
tari_indexer_client ‑ types::export_bindings_indexerconnection
tari_indexer_client ‑ types::export_bindings_indexerconnectiondirection
tari_indexer_client ‑ types::export_bindings_indexergetallvnsrequest
tari_indexer_client ‑ types::export_bindings_indexergetallvnsresponse
tari_indexer_client ‑ types::export_bindings_indexergetcommsstatsresponse
tari_indexer_client ‑ types::export_bindings_indexergetconnectionsresponse
tari_indexer_client ‑ types::export_bindings_indexergetepochmanagerstatsresponse
tari_indexer_client ‑ types::export_bindings_indexergetidentityresponse
…

♻️ This comment has been updated with latest results.

[sdbondi]

Did a quick test this doesnt break any of the WebUIs. LGTM

I have added all generated files (from npm run build command) to .gitignore file - this should prevent from situations where released package comes from older builds.

Was the gitignore change removed? Just checking if we should continue to run npm run build when types change.

Maybe we just need to add a step to build the bindings before running CI - but we can leave that for another PR

[MCozhusheck]

Did a quick test this doesnt break any of the WebUIs. LGTM

I have added all generated files (from npm run build command) to .gitignore file - this should prevent from situations where released package comes from older builds.

Was the gitignore change removed? Just checking if we should continue to run npm run build when types change.

Maybe we just need to add a step to build the bindings before running CI - but we can leave that for another PR

Yes I have reverted changes to the .gitignore and github action workflow so we have more control when we are building type bindings