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