JS SDK support

[maxhr]

• Major refactor
• JS SDK
• CLI user prompts

[volovyks]

Since it will be the main way to create JS contract, let's add instructions here: near/near-sdk-js#145

[volovyks]

The fact that CI does not work for some people in our org is annoying. Why is this happening?

[maxhr]

The fact that CI does not work for some people in our org is annoying. Why is this happening?

@volovyk-s it still breaks on M1 because of workspaces-rs. Is that what you mean?

[gagdiez]

@maxhr I think @volovyk-s means that actions are not being triggered, and that's because the PR comes from another repo. Maybe we should migrate the branch here.

[maxhr]

Yes, forks don't trigger actions on the original. I don't have permissions to push here.

[volovyks]

The fact that CI does not work for some people in our org is annoying. Why is this happening?

@volovyk-s it still breaks on M1 because of workspaces-rs. Is that what you mean?

I meant what @gagdiez said.
Regarding M1 - it should work, both Workspaces RS and JS support M1 on the latest version. But those versions are breaking Mac CI (known issue: near/nearcore#7235).

[idea404]

Looks good. A couple non-blocking comments:

1. Testing - If I read correctly, there is no test in place right now to test recommending WSL for Windows environments. Maybe good to have something like this in place. It would also be nice for the e2e tests to have a summary view once they have run, they produce a lot of output on the terminal atm which is hard to follow.
2. Dependency versioning management - Every template comes with dependencies and each their own versions. I believe it would make the repo easier to maintain if these versions would be specified in one file and these values would be extracted when dApp is created by user.
3. Config management / maintainability - Similar to the point above, I notice the supported languages/frameworks are specified multiple times throughout multiple files in the repo, this can get painful to manage as we add support for more languages and frameworks in the future. I would suggest using a config file and specifying these in the config file and have the rest of the repo read this file.

Also, npm run test fails for the js tests for me in my ubuntu machine.

[idea404]

I've seen definitions like these here and in types.ts (and probably still other parts), would it be perhaps better to define these in a separate config.json file or similar for the entire project once and fetch those definitions from that file instead?

[maxhr]

Agreed

[gagdiez]

@volovyk-s this is ready to be merged

[volovyks]

@gagdiez ok
It is better to create releases from the master. It automatically adds tags and a release here on GitHub. Now we need to do that manually.
And do not forget to use conventional commits in this repo :)