[FEATURE] `wash build`

[brooksmtownsend]

Is your feature request related to a problem? Please describe. The easiest way to compile and sign actors today is to use the included Makefile and run make. This is simple, but constraining to Windows developers and adds an additional tool that's required for the developer to use.

Describe the solution you'd like I would love to have a subcommand, wash build, that auto-detected language (just Rust / TinyGo now, for our examples) and invoked that compiler toolchain on the local machine. In tandem with #262, this could replace the make build/sign steps with a single wash build command that builds and signs the actor.

Auto-detecting language to start can be naive, something like looking for a Cargo.toml or a go.mod file.

Describe alternatives you've considered We could approach this with something like just, though again this just requires an additional install that's more Rust biased.

[mattwilkinsonn]

Probably need to have our own configuration file along with this if we're getting rid of the makefiles, an equivalent to package.json or Cargo.toml. Perhaps just wash.toml? or wasmcloud.toml?

[brooksmtownsend]

Probably need to have our own configuration file along with this if we're getting rid of the makefiles, an equivalent to package.json or Cargo.toml.

I was wondering if we could get away with storing additional metadata in each language's config file just for ease-of-use, but if that can't be done in go.mod / Cargo.toml / package.json / whatever Zig uses / whatever C# uses then disregard

Perhaps just wash.toml? or wasmcloud.toml?

wash.toml would be great for just wash uses, but I think that there's an opportunity here with the wasmcloud-otp notion of a host configuration file since wash and wasmcloud would share NATS connection information... I think wasmcloud.toml is the safer bet even if it starts with just wash configuration values

[mattwilkinsonn]

I was wondering if we could get away with storing additional metadata in each language's config file just for ease-of-use, but if that can't be done in go.mod / Cargo.toml / package.json / whatever Zig uses / whatever C# uses then disregard

I think that's a bit risky to rely on the language's config files, they might not have the features/UX we want, with our own file we can control that much more. Also would lead to us having to parse every other language's config files in wash just to read that data 😅

wash.toml would be great for just wash uses, but I think that there's an opportunity here with the wasmcloud-otp notion of a host configuration file since wash and wasmcloud would share NATS connection information... I think wasmcloud.toml is the safer bet even if it starts with just wash configuration values

Yeah, wasmcloud.toml seems better to me for "project-level" stuff. Perhaps we'll need a wash.toml down the road for specifically setting compiler options and such

[mattwilkinsonn]

Closing this as it was implemented in #297.