Browser support

[rkalis]

Currently, the CashScript JavaScript SDK can only be used inside NodeJS, and not inside a browser environment. There are several things that cause this.

1. antl4ts might be incompatible with a browser environment. antlr4ts has only been tested to work in a NodeJS environment, but there is an open PR for browser support (antlr4ts#413). This would allow compilation of CashScript contracts in-browser. However, for use of Artifacts, it is not needed to use the compiler in-browser.
2. Use of filesystem operations in the SDK that are incompatible with a browser environment. Contract.compile, Contract.import, instance.export, Artifacts.require, Artifacts.export, CashCompiler.compileFIle all read from or write to the local filesystem using fs and path.

The solution to (1) is to wait for this PR to be merged, or contribute to it if necessary.

For (2) we can decide to replace these functions with their equivalents that don't need filesystem access. This would mean that users need to read in the .cash file themselves, then pass in the string into a function like Contract.fromContract. Artifacts can be imported using the regular JavaScript require since they're just JSON files, which makes it all a bit easier when just dealing with artifacts.

In this case it could be valuable to have a Truffle-like workflow for CashScript that handles contract compilation and instantiation, and automatically creates artifact JSON files. Then the JavaScript (or potentially Python, Rust, etc.) application just needs to import the Artifact JSON, which is usually quite simple.

The cashc CLI will always need filesystem access any way, so we should figure out how to make this available to the CLI, while the NPM package doesn't necessarily require it when it is installed into other projects.

We need to think more about the best and most user-friendly way to enable browser support for CashScript.

[cyborgmarina]

@rkalis Regarding (2): During the SLPVH we were thinking about using cashscripts in our client-side app. Initially, to overcome the issues of filesystem operations (fs and path), we aliased fs and path to https://github.com/jvilk/BrowserFS equivalent, and had some success with it.
We struggled a bit with another library, that was using an eval with a require inside it (couldn't remember which one now, but it was related to hashing).

Might be a good workaround, I don't know.

[cyborgmarina]

So... I guess I got it working with BrowserFS, some webpack alias, in a react app:

[pavel-main]

@alcipir Is there any public fork repo available?

[rkalis]

Hey @pavel-main! @alcipir created the cashscript-components repo in which he got CashScript running in web.

Ideally, the code @alcipir used to make it work in that repository should be integrated into the build process for the cashc and cashscript libraries, so that they can be used in web projects out of the box. Unfortunately, figuring out this build process is not really my forte, so any help on this is appreciated.

[cyborgmarina]

Incoming PR #52, need help with testing.

[SahidMiller]

Hello! I'm glad to see some activity with this. I just sat down for a bit to get this working in the browser as well. Below is a screenshot of what seems to be working.

I'm curious if I'm missing anything and I'm hesitant to say it is working because I still need to learn BitBox API and Bitcoin Scripting in general to really test it and get rolling, God willing.

AFAIK as long as we:

1. can pass an optimizationSchema string as a parameter to down to TargetCodeOptimisation.optimize and/or expose a TargetCodeOptimisation.updateDefaultOptimizationSchema

And

2. Stub out the fs module by adding a webpack configuration step node: { fs: 'empty' }.

Then you'd be get the result in the screenshot above.

[rkalis]

This is released in v0.3.2