You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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.ts
approach)Biggest downsides at the moment are
The text was updated successfully, but these errors were encountered: