1 Context

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.

2 Possible approaches

I see two possible ways of processing the main.wasp.ts file:

  1. Treating 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).
  2. Treating 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):

  1. The user gets an API which they use to define their application in main.wasp.ts.
  2. The user writes their app definition in main.wasp.ts.
  3. The user runs wasp start.

So, let’s see what happens under the hood in each approach.

2.1 Treating main.wasp.ts as a program

This approach uses two processes in two different runtimes:

Here’s what happens after the user defines their app in main.wasp.ts and calls the wasp start command:

  1. The wasp start process starts the external TS SDK process (let’s say its entry point is the run-sdk.ts file).
  2. The TS SDK process imports main.wasp.ts as a normal TS/JS module and executes its code.
  3. The result of executing main.wasp.ts is an App config object (i.e., an AppSpec in TypeScript).
  4. The code inside run-sdk.ts serializes the App config object (most likely into a JSON string, let’s call it AppSpec.json).
  5. The TS SDK process passes the serialized AppSpec.json to the running wasp start command (through stdout, a file, or something else).
  6. wasp start deserializes the App config object into an AppSpec object and passes it into the Generator.
  7. From this point, it’s business as usual.

Here’s a chart to help you visualize the entire process:

shapes at 24-06-19 13.52.06.png

2.2 Treating main.wasp.ts as an input