Large workspaces end up with a very large number of possible build
configurations.
Even worse, the feature set of a package affects everything that depends
on it, so syn being built with a slightly different feature set than
before would cause *every package that directly or transitively depends
on syn to be rebuilt. For large workspaces, this can result a lot of
wasted build time.
To avoid this problem, many large workspaces contain a workspace-hack
crate. The purpose of this package is to ensure that dependencies like
syn are always built with the same feature set no matter which workspace
packages are currently being built. This is done by:
1) adding dependencies like syn to workspace-hack with the full feature
set required by any package in the workspace
2) adding workspace-hack as a dependency of every crate in the
repository.
cargo-hakari manages a workspace-hack crate for you.
Introduce starmelon, a program for executing elm functions with input
from files and writing the output back to files.
Support evaluating 4 types of values and 12 types of functions.
```elm
x : String
x : Bytes
x : VirtualDom.Node msg
x : Json.Encode.Value
f : String -> String
f : String -> Bytes
f : String -> VirtualDom.Node msg
f : String -> Json.Encode.Value
f : Bytes -> String
f : Bytes -> Bytes
f : Bytes -> VirtualDom.Node msg
f : Bytes -> Json.Encode.Value
f : Json.Encode.Value -> String
f : Json.Encode.Value -> Bytes
f : Json.Encode.Value -> VirtualDom.Node msg
f : Json.Encode.Value -> Json.Encode.Value
```
My target use case for starmelon is generating html files. It is nice
to be able to write parameterized framgents of markup in multiple
modules and then compose them into a final value. I also have in mind
attempting to replace helm (kubernetes pacakge manager) because I hate
how error prone its string based templating language is.
