Support debug and release builds

[itowlson]

Many build systems have the concept of debug and release builds (under various names), and output these at different paths.

As a developer, I want to maintain a single HIPPOFACTS file such that:

• I can deploy local debug builds interactively using quick hippofactory . syntax
• I can deploy local release builds interactively with slightly more effort
• I can deploy release builds from CI

Not all file paths will necessarily change in the same way, e.g. WASM modules may change between bin/debug and bin/release directories while CSS files remain under styles and JavaScript files change from dist/*.js to dist/*.min.js.

To be decided: should we provide a way to map file paths e.g. bin/debug/*.wasm => bin? This allows file paths to be the same regardless of debug vs release... but in that case shouldn't the build system be putting them in the 'right' place?

Hippofactory should be agnostic about build systems; therefore, any knowledge of paths, filenames, etc. should be confined to the HIPPOFACTS file.

[itowlson]

Syntax ideas for HIPPOFACTS (to be clear: these are alternatives, not suggesting we do all of them!):

1. name and files can be table as well as string

# Same in all build configurations
[[handler]]
name = "foo.wasm"

# Distinct release build with same files
[[handler]]
name.release = "targets/wasm32-wasi/release/foo.wasm"
name.default = "targets/wasm32-wasi/debug/foo.wasm"
files = ["styles/*.css"]

# Distinct release build with differentfiles
[[handler]]
name.release = "targets/wasm32-wasi/release/foo.wasm"
files.release = ["scripts/*.min.js"]
name.default = "targets/wasm32-wasi/debug/foo.wasm"
files.default = ["scripts/*.js"]

2. Specify variable in path

[[handler]]
name = "targets/wasm32-wasi/$(HIPPO_BUILD_ID)/foo.wasm"

This is less flexible and we can't readily do things like the minified files trick with it.

3. Conditional handlers

# Same in all build configurations
[[handler]]
name = "foo.wasm"

# Only in non-release runs
[[handler]]
condition = "$build_kind != 'release'"
name = "targets/wasm32-wasi/debug/foo.wasm"
files = ["scripts/*.js"]

# Only in release runs
[[handler]]
condition = "$build_kind == 'release'"
name = "targets/wasm32-wasi/release/foo.wasm"
files = ["scripts/*.min.js"]

How should HF choose between them?

Obvious solution is a --build-id or --build-kind flag which defaults to empty or to debug, so we can retain the hippo push . experience. Is there anything better?

Other thoughts

• We should probably annotate the bindle to indicate what kind of build it is picking up e.g. hippo:buildKind = "release".
• Is it too easy in the dev environment to accidentally ship a debug build instead of a more recent release build? (And then spend hours wondering why your code change doesn't seem to do anything.) E.g. should we check the module timestamps and print a message if the 'other' build, whatever that means, is more recent?

[itowlson]

The timestamp thing actually makes me wonder:

4. Choose most recent from a name array

[[handler]]
name = ["targets/wasm32-wasi/debug/foo.wasm", "targets/wasm32-wasi/release/foo.wasm"]

And we would pick the file in the array with the most recent timestamp.

This feels a bit unpredictable though. But maybe it is salvageable or has a useful kernel to it.

[bacongobbler]

no longer relevant after merging #121.