In playing with manifests and generating metadata files from config + filesystem state, we found that we could maybe resolve some issues/complexity around TS by writing config output to a strongly typed JSON file. This has a few nice side effects:
we don't need to duplicate logic between JS runtime + TS types, instead the output is just JS runtime written to a file (and made strongly typed with our .json.d.ts approach)
we get a platform-agnostic representation of the MUD config that can be used outside TS tooling
we can combine data read from filesystem into the input (i.e. systems), where before this is impossible due to config output being used in the client where the filesystem is not accessible
we could separate out things that are irrelevant to the app's runtime (codegen options, deploy options) into their own files that don't need strong types
Biggest downsides at the moment are
we add a build step between writing a config and using it downstream.
we're limited to values being JSON serializable, so we can't encode things like functions, references, etc. (but we don't use this at the moment anyway)
In playing with manifests and generating metadata files from config + filesystem state, we found that we could maybe resolve some issues/complexity around TS by writing config output to a strongly typed JSON file. This has a few nice side effects:
.json.d.tsapproach)Biggest downsides at the moment are