Before discussing the TS DSL’s design, we must decide how to process it. The way we process the file has implications for what we can do with its design.
I see two possible ways of processing the main.wasp.ts file:
main.wasp.ts as a program.
We create a different Node.js process and execute the main.wasp.ts file directly (using TS Node **or TSC + Node.js).main.wasp.ts as an input.
We read and process the main.waps.ts file inside our usual Haskell runtime.From the user’s perspective, the two approaches are identical (at least on the happy path):
main.wasp.ts.main.wasp.ts.wasp start.So, let’s see what happens under the hood in each approach.
main.wasp.ts as a programThis approach uses two processes in two different runtimes:
wasp start command.
I use purple text when talking about files executed in this runtime.main.wasp.ts file.
I use blue text when talking about files executed in this runtime.Here’s what happens after the user defines their app in main.wasp.ts and calls the wasp start command:
wasp start process starts the external TS SDK process (let’s say its entry point is the run-sdk.ts file).main.wasp.ts as a normal TS/JS module and executes its code.main.wasp.ts is an App config object (i.e., an AppSpec in TypeScript).run-sdk.ts serializes the App config object (most likely into a JSON string, let’s call it AppSpec.json).AppSpec.json to the running wasp start command (through stdout, a file, or something else).wasp start deserializes the App config object into an AppSpec object and passes it into the Generator.Here’s a chart to help you visualize the entire process:

main.wasp.ts as an input