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.
To generate partial application boxed closures I need to know the arity
of the expression to tell if more args will remain after the given args.
Right now I think I can recalculate the types if I have a symbol table
where I can look up every variable. I think this will be a lot of work
because I have to reimplement most of unification to deal with
collections, patterns, and type variables. And I currently don't know
how unification works.
Move some of the caching logic (source file checksum) out of Starmelon
into a shared infra crate.
I have 4 similar tooling use cases for working with elm projects in
Rust.
1. Starmelon needs to create a modified copy of an existing elm
application with extra dependencies and source directories. The
extension elm application points to the source directories of the
parent
2. Elm reactor needs to compile an elm module into javascript with
caching.
3. SQL reactor needs to generate an elm application for each database,
generate elm source code and compile that elm code with caching. It
uses Starmelon to run derive macros written in Elm.
4. AstridLabs needs to create a heavily modified copy of an existing elm
application with tons of generated code. It uses Starmelon to run
derive macros written in Elm.
For 3 and 4 I could speed up the code generation step by using
part of starmelon as library. A proc-macro could include the Elm derive
macro javascript at crate build time and reuse the same v8 isolate over
and over for every web request.
My plan for 1,2,3,4 has a lot of shared functionality. I am thinking
that I should consolidate all the components into one library crate.
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.
