### Setup Function for Client-Side Logic (JavaScript)

Source: https://wasp.sh/llms-full-0.11.8.txt

Example of a client-side setup function in JavaScript that runs before the application initializes. This example logs a message hourly.

```js
export default async function mySetupFunction() {
  let count = 1
  setInterval(
    () => console.log(`You have been online for ${count++} hours.`),
    1000 * 60 * 60
  )
}
```

--------------------------------

### Setup Function for Client-Side Logic (TypeScript)

Source: https://wasp.sh/llms-full-0.11.8.txt

Example of a client-side setup function in TypeScript that runs before the application initializes. This example logs a message hourly, with type annotations.

```ts
export default async function mySetupFunction(): Promise<void> {
  let count = 1
  setInterval(
    () => console.log(`You have been online for ${count++} hours.`),
    1000 * 60 * 60
  )
}
```

--------------------------------

### Router Use Example

Source: https://wasp.sh/llms-full-0.11.8.txt

This is an example of how the custom middleware is installed at the router level for a specific path.

```javascript
router.use('/foo/bar', fooBarNamespaceMiddleware)
```

--------------------------------

### Server Setup Function

Source: https://wasp.sh/llms-full-0.11.8.txt

The `setupFn` allows you to define an asynchronous function that runs on server start. It receives the Express application and HTTP server instances, enabling custom server configurations, route setups, or starting background tasks.

```APIDOC
## Server Setup Function (`setupFn`)

### Description
Declares a Javascript or Typescript function that will be executed on server start. This function is expected to be async and will be awaited before the server starts accepting any requests. It allows for custom setup like additional database/websockets or starting cron/scheduled jobs.

### Context
The `setupFn` function receives the `express.Application` and the `http.Server` instances as part of its context. They can be useful for setting up any custom server routes or for example, setting up `socket.io`.

### JavaScript Example
```js
export const mySetupFunction = async () => {
  await setUpSomeResource()
}
```

### TypeScript Example
#### Types
```ts
export type ServerSetupFn = (context: ServerSetupFnContext) => Promise<void>

export type ServerSetupFnContext = {
  app: Application // === express.Application
  server: Server // === http.Server
}
```

#### Implementation
```ts
import { ServerSetupFn } from '@wasp/types'

export const mySetupFunction: ServerSetupFn = async () => {
  await setUpSomeResource()
}
```
```

--------------------------------

### Example API Definition (GET /foo/bar)

Source: https://wasp.sh/llms-full-0.13.txt

An example of how to define an API named 'fooBar' that handles GET requests to '/foo/bar', uses the 'Task' entity, requires authentication, and applies custom middleware.

```APIDOC
## GET /foo/bar

### Description
This API endpoint, named 'fooBar', is designed to handle GET requests and is associated with the '/foo/bar' route. It has access to the 'Task' entity and requires authentication. Custom middleware can also be applied.

### Method
GET

### Endpoint
/foo/bar

### Parameters
#### Request Body
(Not specified in the source)

### Request Example
(Not specified in the source)

### Response
#### Success Response (200)
- **count** (number) - The count of tasks, accessed via the 'Task' entity.

### Response Example
```json
{
  "count": 10
}
```
```

--------------------------------

### Server Setup Function

Source: https://wasp.sh/llms-full-0.15.txt

The `setupFn` allows you to execute custom asynchronous logic when the Wasp server starts. This is useful for initializing resources, setting up databases, or starting background jobs. The function receives the Express application and HTTP server instances.

```APIDOC
## `setupFn`

### Description
Declares a JavaScript or TypeScript function that will be executed on server start. This function is expected to be async and will be awaited before the server starts accepting any requests. It allows for custom setup like additional database/websocket connections or cron jobs.

### Parameters
- `context` (ServerSetupFnContext) - The context object containing the Express application and HTTP server instances.
  - `app` (express.Application) - The Express application instance.
  - `server` (http.Server) - The HTTP server instance.

### Request Example (JavaScript)
```js
export const mySetupFunction = async () => {
  await setUpSomeResource()
}
```

### Response Example (TypeScript Types)
```ts
export type ServerSetupFn = (context: ServerSetupFnContext) => Promise<void>

export type ServerSetupFnContext = {
  app: Application // === express.Application
  server: Server // === http.Server
}
```
```

--------------------------------

### Wasp TS Configuration Example

Source: https://wasp.sh/docs/0.16/general/wasp-ts-config

This is a comprehensive example of a main.wasp.ts file, demonstrating how to configure various aspects of a Wasp application, including authentication, server and client setup, database seeding, and API definitions.

```typescript
import { App } from 'wasp-config'
const app = new App('todoApp', {
  title: 'ToDo App',
  wasp: { version: '^0.24' },
  // head: []
});
app.webSocket({
  fn: { import: 'webSocketFn', from: '@src/webSocket' },
  // autoConnect: false
});
app.auth({
  userEntity: 'User',
  methods: {
    discord: {
      configFn: { import: 'config', from: '@src/auth/discord' },
      userSignupFields: { import: 'userSignupFields', from: '@src/auth/discord' }
    },
    google: {
      configFn: { import: 'config', from: '@src/auth/google' },
      userSignupFields: { import: 'userSignupFields', from: '@src/auth/google' }
    },
    gitHub: {
      configFn: { import: 'config', from: '@src/auth/github.js' },
      userSignupFields: { import: 'userSignupFields', from: '@src/auth/github.js' }
    },
    // keycloak: {},
    // email: {
    //   userSignupFields: { import: 'userSignupFields', from: '@src/auth/email' },
    //   fromField: {
    //     name: 'ToDO App',
    //     email: '[email protected]'
    //   },
    //   emailVerification: {
    //     getEmailContentFn: { import: 'getVerificationEmailContent', from: '@src/auth/email' },
    //     clientRoute: 'EmailVerificationRoute',
    //   },
    //   passwordReset: {
    //     getEmailContentFn: { import: 'getPasswordResetEmailContent', from: '@src/auth/email' },
    //     clientRoute: 'PasswordResetRoute'
    //   }
    // },
  },
  onAuthFailedRedirectTo: '/login',
  onAuthSucceededRedirectTo: '/profile',
  onBeforeSignup: { import: 'onBeforeSignup', from: '@src/auth/hooks.js' },
  onAfterSignup: { import: 'onAfterSignup', from: '@src/auth/hooks.js' },
  onBeforeOAuthRedirect: { import: 'onBeforeOAuthRedirect', from: '@src/auth/hooks.js' },
  onBeforeLogin: { import: 'onBeforeLogin', from: '@src/auth/hooks.js' },
  onAfterLogin: { import: 'onAfterLogin', from: '@src/auth/hooks.js' }
});
app.server({
  setupFn: { importDefault: 'setup', from: '@src/serverSetup' },
  middlewareConfigFn: { import: 'serverMiddlewareFn', from: '@src/serverSetup' },
});
app.client({
  rootComponent: { import: 'App', from: '@src/App' },
  setupFn: { importDefault: 'setup', from: '@src/clientSetup' }
});
app.db({
  seeds: [
    { import: 'devSeedSimple', from: '@src/dbSeeds' },
  ]
});
app.emailSender({
  provider: 'SMTP',
  defaultFrom: { email: '[email protected]' }
});
const loginPage = app.page('LoginPage', {
  component: { importDefault: 'Login', from: '@src/pages/auth/Login' }
});
app.route('LoginRoute', { path: '/login', to: loginPage });
app.query('getTasks', {
  fn: { import: 'getTasks', from: '@src/queries' },
  entities: ['Task']
});
app.action('createTask', {
  fn: { import: 'createTask', from: '@src/actions' },
  entities: ['Task']
});
app.apiNamespace('bar', {
  middlewareConfigFn: { import: 'barNamespaceMiddlewareFn', from: '@src/apis' },
  path: '/bar'
});
app.api('barBaz', {
  fn: { import: 'barBaz', from: '@src/apis' },
  auth: false,
  entities: ['Task'],
  httpRoute: {
    method: 'GET',
    route: '/bar/baz',
  },
});
app.job('mySpecialJob', {
  executor: 'PgBoss',
  perform: {
    fn: { import: 'foo', from: '@src/jobs/bar' },
    executorOptions: {
      pgBoss: { retryLimit: 1 }
    }
  },
  entities: ['Task']
});
export default app;

```

--------------------------------

### Install Wasp from Source

Source: https://wasp.sh/llms-full-0.11.8.txt

Clone the Wasp repository and use Cabal to install if the script installer is not suitable.

```shell
cabal install
```

--------------------------------

### Install WSL

Source: https://wasp.sh/blog/2023/11/21/guide-windows-development-wasp-wsl

Execute this command in Administrator mode (Powershell) to initiate the installation of the Windows Subsystem for Linux.

```powershell
wsl —install
```

--------------------------------

### Add Custom Route (TypeScript)

Source: https://wasp.sh/llms-full-0.12.txt

Example of adding a custom GET route to the Express application within the server setup function using TypeScript.

```ts
import { ServerSetupFn } from 'wasp/server'
import { Application } from 'express'

export const mySetupFunction: ServerSetupFn = async ({ app }) => {
  addCustomRoute(app)
}

function addCustomRoute(app: Application) {
  app.get('/customRoute', (_req, res) => {
    res.send('I am a custom route')
  })
}
```

--------------------------------

### setup

Source: https://wasp.sh/llms-full-0.12.txt

The `setup` command creates your client and server applications on Fly.io, including necessary secrets, but does not deploy them. It generates `fly-server.toml` and `fly-client.toml` files for further configuration.

```APIDOC
## `setup`

### Description
`setup` will create your client and server apps on Fly, and add some secrets, but does _not_ deploy them. It generates `fly-server.toml` and `fly-client.toml` files for further configuration.

### Method
```shell
wasp deploy fly setup <app-name> <region>
```

### Parameters
#### Path Parameters
- **`<app-name>`** (string) - Required - The name of your app.
- **`<region>`** (string) - Required - The region where your app will be deployed. Read how to find the available regions [here](#flyio-regions).

### Notes
- After running `setup`, Wasp creates two new files in your project root directory: `fly-server.toml` and `fly-client.toml`. You should include these files in your version control.
- You **can edit the `fly-server.toml` and `fly-client.toml` files** to further configure your Fly deployments. Wasp will use the TOML files when you run `deploy`.
- If you want to maintain multiple apps, you can add the `--fly-toml-dir <abs-path>` option to point to different directories, like "dev" or "staging".

:::caution Execute Only Once
You should only run `setup` once per app. If you run it multiple times, it will create unnecessary apps on Fly.
:::
```

--------------------------------

### Wasp Fly Setup Command Reference

Source: https://wasp.sh/llms-full-0.11.8.txt

The `setup` command creates your client and server apps on Fly and adds initial secrets, but does not deploy them. It requires the app name and region.

```shell
wasp deploy fly setup <app-name> <region>
```

--------------------------------

### Launch Fly.io App and Create fly.toml

Source: https://wasp.sh/docs/0.21/deployment/deployment-methods/paas

Use this command to set up a new Fly.io app and generate a `fly.toml` configuration file. It prompts for region and database setup. Respond 'yes' to database setup and 'no' to immediate deployment.

```bash
cd .wasp/out
fly launch --remote-only
```

--------------------------------

### Configure Client with Root Component and Setup Function (JavaScript)

Source: https://wasp.sh/llms-full-0.11.8.txt

Configure the client with a root component and a setup function in JavaScript. Ensure the paths to your client components are correct.

```wasp
app MyApp {
  title: "My app",
  // ...
  client: {
    rootComponent: import Root from "@client/Root.jsx",
    setupFn: import mySetupFunction from "@client/myClientSetupCode.js"
  }
}
```

--------------------------------

### Client-side API Call (GET /foo/bar)

Source: https://wasp.sh/llms-full-0.15.txt

Example of how to call a Wasp API endpoint from the client-side using the `api` wrapper provided by `wasp/client/api`. This example demonstrates making a GET request to the '/foo/bar' endpoint.

```APIDOC
## Client-side API Call (GET /foo/bar)

### Description
This client-side code demonstrates how to invoke a Wasp API endpoint from your frontend application. It uses the `api` object imported from `wasp/client/api` to make a GET request to the `/foo/bar` endpoint and logs the response data.

### Method
GET

### Endpoint
/foo/bar

### Parameters
N/A

### Request Example
N/A

### Response
#### Success Response
- **data** (any) - The data returned from the API endpoint.

#### Response Example
```json
{
  "msg": "Hello, stranger!"
}
```
```

--------------------------------

### Create New Wasp Project with `wasp new`

Source: https://wasp.sh/llms-full-0.11.8.txt

Demonstrates the interactive process of creating a new Wasp project, including naming the project and selecting a starter template. This is the standard way to initialize a Wasp project.

```bash
$ wasp new
Enter the project name (e.g. my-project) ▸ MyFirstProject
Choose a starter template
[1] basic (default)
[2] saas
[3] todo-ts
▸ 1

🐝 --- Creating your project from the basic template... ---------------------------

Created new Wasp app in ./MyFirstProject directory!
To run it, do:

    cd MyFirstProject
    wasp start
```

--------------------------------

### Example Project Structure (After)

Source: https://wasp.sh/llms-full-0.14.txt

Shows a recommended feature-based structure for the src directory after removing the client/server separation.

```tree
src
│
├── task
│	├── actions.ts    -- former taskActions.ts
│	├── queries.ts    -- former taskQueries.ts
│	├── Task.css
│	├── TaskLisk.tsx
│	└── Task.tsx
├── user
│	├── actions.ts    -- former userActions.ts
│	├── Dashboard.tsx
│	├── Login.tsx
│	├── queries.ts    -- former userQueries.ts
│	├── Register.tsx
│	└── User.tsx
├── MainPage.tsx
└── utils.ts
```

--------------------------------

### JavaScript Server Setup Function

Source: https://wasp.sh/llms-full-0.11.8.txt

Define an asynchronous setup function for the Wasp server in JavaScript. This function is executed on server start.

```js
export const mySetupFunction = async () => {
  await setUpSomeResource()
}
```

--------------------------------

### Get First Provider User ID in React Component (TypeScript)

Source: https://wasp.sh/llms-full-0.15.txt

TypeScript example for getting the primary user ID in a React component. Requires AuthUser type import.

```tsx
import { type AuthUser } from 'wasp/auth'

const MainPage = ({ user }: { user: AuthUser }) => {
  const userId = user.getFirstProviderUserId()
  // ...
}
```

--------------------------------

### Example Project Structure (Before)

Source: https://wasp.sh/llms-full-0.14.txt

Illustrates the typical server/client separation in the src directory before reorganization.

```tree
src
│
├── client
│	├── Dashboard.tsx
│	├── Login.tsx
│	├── MainPage.tsx
│	├── Register.tsx
│	├── Task.css
│	├── TaskLisk.tsx
│	├── Task.tsx
│	└── User.tsx
├── server
│	├── taskActions.ts
│	├── taskQueries.ts
│	├── userActions.ts
│	└── userQueries.ts
└── shared
    └── utils.ts
```

--------------------------------

### Access Stored Values in Query (JavaScript)

Source: https://wasp.sh/llms-full-0.14.txt

Example of accessing values stored during server setup from a Wasp query in JavaScript.

```js
import { getSomeResource } from './myServerSetupCode.js'

...

export const someQuery = async (args, context) => {
  const someResource = getSomeResource()
  return queryDataFromSomeResource(args, someResource)
}
```

--------------------------------

### Start Development Database

Source: https://wasp.sh/

Spins up a local development database.

```bash
wasp start db
```

--------------------------------

### Example Project Structure (Before Reorganization)

Source: https://wasp.sh/llms-full-0.13.txt

Illustrates the typical client/server/shared directory structure before adopting a feature-based organization.

```tree
src
│
├── client
│   ├── Dashboard.tsx
│   ├── Login.tsx
│   ├── MainPage.tsx
│   ├── Register.tsx
│   ├── Task.css
│   ├── TaskLisk.tsx
│   ├── Task.tsx
│   └── User.tsx
├── server
│   ├── taskActions.ts
│   ├── taskQueries.ts
│   ├── userActions.ts
│   └── userQueries.ts
└── shared
    └── utils.ts
```

--------------------------------

### Customize Global Middleware (Wasp - JavaScript)

Source: https://wasp.sh/llms-full-0.17.txt

Example of configuring global middleware in Wasp using a JavaScript server setup file.

```wasp
app todoApp {
  // ...

  server: {
    middlewareConfigFn: import { serverMiddlewareFn } from "@src/serverSetup"
  },
}
```

--------------------------------

### Launch Fly.io App

Source: https://wasp.sh/llms-full-0.17.txt

Initiates a new Fly.io application, sets up a database if prompted, and creates a `fly.toml` configuration file. It's recommended to say 'no' to deploying immediately.

```bash
fly launch --remote-only
```

--------------------------------

### JavaScript Prisma Client Setup with Logging and Extensions

Source: https://wasp.sh/llms-full.txt

Set up a Prisma Client instance in JavaScript, enabling query logging and adding a client extension to filter tasks.

```javascript
import { PrismaClient } from "@prisma/client"

export const setUpPrisma = () => {
  const prisma = new PrismaClient({
    log: ["query"],
  }).$extends({
    query: {
      task: {
        async findMany({ args, query }) {
          args.where = {
            ...args.where,
            description: { not: { contains: "hidden by setUpPrisma" } },
          }
          return query(args)
        },
      },
    },
  })

  return prisma
}
```

--------------------------------

### Adding Tailwind Plugins to Config

Source: https://wasp.sh/llms-full-0.14.txt

Register installed Tailwind plugins in your `tailwind.config.cjs` file to enable their functionality. This example adds the forms and typography plugins.

```javascript
/** @type {import('tailwindcss').Config} */
module.exports = {
  // ...
  plugins: [
    require('@tailwindcss/forms'),
    require('@tailwindcss/typography'),
  ],
  // ...
```

--------------------------------

### Wasp Auth Configuration (0.11.X)

Source: https://wasp.sh/llms-full-0.12.txt

Example of Wasp authentication configuration in version 0.11.X, requiring manual setup of user and external auth entities.

```wasp
app myApp {
  wasp: {
    version: "^0.11.0"
  },
  title: "My App",
  auth: {
    userEntity: User,
    externalAuthEntity: SocialLogin,
    methods: {
      gitHub: {}
    },
    onAuthFailedRedirectTo: "/login"
  },
}

entity User {=psl
  id                        Int           @id @default(autoincrement())
  username                  String        @unique
  password                  String
  externalAuthAssociations  SocialLogin[]
psl=}

entity SocialLogin {=psl
  id          Int       @id @default(autoincrement())
  provider    String
  providerId  String
  user        User      @relation(fields: [userId], references: [id], onDelete: Cascade)
  userId      Int
  createdAt   DateTime  @default(now())
  @@unique([provider, providerId, userId])
psl=}

```

--------------------------------

### Configure Email Authentication in main.wasp

Source: https://wasp.sh/llms-full-0.18.txt

Example of configuring email authentication and an email sender within the main.wasp file. This setup is necessary for enabling email-based authentication flows.

```wasp
app myApp {
  auth: { ... },
  emailSender: { ... }
}

// Defining routes and pages
route SignupRoute { ... }
page SignupPage { ... }
// ...
```

--------------------------------

### Deploy Wasp Client to Netlify (Initial)

Source: https://wasp.sh/docs/0.21/deployment/deployment-methods/paas

Perform an initial deployment of the Wasp client to Netlify. Follow the on-screen prompts to configure the app.

```bash
npx netlify-cli deploy
```

--------------------------------

### Root Component JSX for Provider Setup (JavaScript)

Source: https://wasp.sh/llms-full-0.11.8.txt

Example of a root component in JSX that wraps children with a Redux Provider. Requires importing the store and Provider component.

```jsx
import store from './store'
import { Provider } from 'react-redux'

export default function Root({ children }) {
  return <Provider store={store}>{children}</Provider>
}
```

--------------------------------

### Start Wasp Development Server

Source: https://wasp.sh/llms-full.txt

Navigate into your project directory and run this command to start the Wasp development server. The first run may take some time as it sets up the client, server, and database.

```sh
cd TodoApp
wasp start
```

--------------------------------

### Custom Domain Setup

Source: https://wasp.sh/llms-full-0.16.txt

Guides users through setting up a custom domain for their Fly.io deployed Wasp application, including adding DNS records and configuring environment variables.

```APIDOC
## Custom Domain Setup

### Description
This process allows you to use a custom domain for your Wasp application deployed on Fly.io. It involves adding the domain to your Fly client app, configuring DNS records, and setting the `WASP_WEB_CLIENT_URL` environment variable.

### Steps

1.  **Add Domain to Fly Client App**:
    Run the following command, replacing `mycoolapp.com` with your actual domain:
    ```shell
    wasp deploy fly cmd --context client certs create mycoolapp.com
    ```
    This command will output the necessary DNS record instructions.

2.  **Add DNS Records**:
    Based on the output from the previous step, add the specified A and AAAA records to your domain's DNS service.
    Example output:
    ```shell-session
    You can direct traffic to mycoolapp.com by:

    1: Adding an A record to your DNS service which reads

        A @ 66.241.1XX.154

    You can validate your ownership of mycoolapp.com by:

    2: Adding an AAAA record to your DNS service which reads:

        AAAA @ 2a09:82XX:1::1:ff40
    ```

3.  **Set `WASP_WEB_CLIENT_URL` Environment Variable**:
    Configure the server app's environment variable to point to your custom domain:
    ```shell
    wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=https://mycoolapp.com
    ```

### Adding a `www` Subdomain

To also access your app via `https://www.mycoolapp.com`:

1.  **Generate Certs for `www` Subdomain**:
    ```shell
    wasp deploy fly cmd --context client certs create www.mycoolapp.com
    ```

2.  **Add CNAME Record**:
    Add a CNAME record for `www` pointing to your root domain.
    Example DNS Record:
    | Type  | Name | Value         | TTL  | 
    | ----- | ---- | ------------- | ---- |
    | CNAME | www  | mycoolapp.com | 3600 |

### CORS Configuration

If using both `www` and non-`www` domains, update your CORS configuration to allow requests from both. Refer to [custom CORS configuration](https://gist.github.com/infomiho/5ca98e5e2161df4ea78f76fc858d3ca2) for details.
```

--------------------------------

### launch

Source: https://wasp.sh/llms-full-0.12.txt

The `launch` command is a convenience command that sequentially runs `setup`, `create-db`, and `deploy`. It is used to initiate the deployment process for a new application on Fly.io.

```APIDOC
## `launch`

### Description
`launch` is a convenience command that runs `setup`, `create-db`, and `deploy` in sequence. It is used to initiate the deployment process for a new application on Fly.io.

### Method
```shell
wasp deploy fly launch <app-name> <region>
```

### Parameters
#### Path Parameters
- **`<app-name>`** (string) - Required - The name of your app.
- **`<region>`** (string) - Required - The region where your app will be deployed. Read how to find the available regions [here](#flyio-regions).

### Environment Variables
If you are deploying an app that requires any other environment variables (like social auth secrets), you can set them with the `--server-secret` option:

```shell
wasp deploy fly launch my-wasp-app mia --server-secret GOOGLE_CLIENT_ID=<...> --server-secret GOOGLE_CLIENT_SECRET=<...>
```
```

--------------------------------

### Navigate and Start Wasp Development Server

Source: https://wasp.sh/llms-full-0.11.8.txt

After creating a project, change into the project directory and start the development server. The first run may take longer.

```sh
$ cd TodoApp
$ wasp start
```

--------------------------------

### Store Values for Later Use in TypeScript

Source: https://wasp.sh/llms-full-0.13.txt

Store values in a module-level variable within the setup function for later use by operations in TypeScript. This example demonstrates storing a resource.

```ts
import { type ServerSetupFn } from 'wasp/server'

let someResource = undefined

export const mySetupFunction: ServerSetupFn = async () => {
  // Let's pretend functions setUpSomeResource and startSomeCronJob
  // are implemented below or imported from another file.
  someResource = await setUpSomeResource()
  startSomeCronJob()
}

export const getSomeResource = () => someResource
```

```ts
import { type SomeQuery } from 'wasp/server/operations'
import { getSomeResource } from './myServerSetupCode.js'

... 

export const someQuery: SomeQuery<...> = async (args, context) => {
  const someResource = getSomeResource()
  return queryDataFromSomeResource(args, someResource)
}
```

--------------------------------

### Configure Client with Root Component and Setup Function (TypeScript)

Source: https://wasp.sh/llms-full-0.11.8.txt

Configure the client with a root component and a setup function in TypeScript. Ensure the paths to your client components are correct.

```wasp
app MyApp {
  title: "My app",
  // ...
  client: {
    rootComponent: import Root from "@client/Root.tsx",
    setupFn: import mySetupFunction from "@client/myClientSetupCode.ts"
  }
}
```

--------------------------------

### Store Values for Later Use in JavaScript

Source: https://wasp.sh/llms-full-0.13.txt

Store values in a module-level variable within the setup function for later use by operations in JavaScript. This example demonstrates storing a resource.

```js
let someResource = undefined

export const mySetupFunction = async () => {
  // Let's pretend functions setUpSomeResource and startSomeCronJob
  // are implemented below or imported from another file.
  someResource = await setUpSomeResource()
  startSomeCronJob()
}

export const getSomeResource = () => someResource
```

```js
import { getSomeResource } from './myServerSetupCode.js'

... 

export const someQuery = async (args, context) => {
  const someResource = getSomeResource()
  return queryDataFromSomeResource(args, someResource)
}
```

--------------------------------

### Wasp Fly Launch Command Reference

Source: https://wasp.sh/llms-full-0.11.8.txt

The `launch` command is a convenience wrapper for `setup`, `create-db`, and `deploy`. It requires the app name and region.

```shell
wasp deploy fly launch <app-name> <region>
```

--------------------------------

### Signup Form Component (JavaScript)

Source: https://wasp.sh/llms-full-0.12.txt

Embed Wasp's SignupForm component to handle user registration. This JavaScript example shows the basic setup for rendering the signup form.

```jsx
import { SignupForm } from 'wasp/client/auth'

export function SignupPage() {
  return (
    <div
      style={{
        display: 'grid',
        placeContent: 'center',
      }}
    >
      <SignupForm />
    </div>
  )
}
```

--------------------------------

### Create SaaS Template

Source: https://wasp.sh/llms-full-0.11.8.txt

Use this command to quickly start a new project with the SaaS template, which includes Stripe Payments, OpenAI GPT API, Google Auth, SendGrid, Tailwind, and Cron Jobs.

```bash
wasp new <project-name> -t saas
```

--------------------------------

### Example Data Migration Function for GitHub Auth

Source: https://wasp.sh/docs/0.12/migration-guide

A TypeScript function to migrate existing user data for GitHub authentication. This can be used as a starting point and copied directly into your project.

```typescript
import { type User, type GitHubAuth } from "@wasp/entities";
import { type Context } from "@wasp/api";

export async function migrateGithub(ctx: Context, user: User, githubAuth: GitHubAuth) {
  // If the user already has a githubAuth entry, we don't need to do anything.
  if (githubAuth) {
    return;
  }

  // Create a new githubAuth entry for the user.
  await ctx.entities.GitHubAuth.create({
    data: {
      user: {
        connect: { id: user.id },
      },
      githubId: githubAuth.githubId,
    },
  });
}
```

--------------------------------

### Example Data Migration Function for Google Auth

Source: https://wasp.sh/docs/0.12/migration-guide

A TypeScript function to migrate existing user data for Google authentication. This can be used as a starting point and copied directly into your project.

```typescript
import { type User, type GoogleAuth } from "@wasp/entities";
import { type Context } from "@wasp/api";

export async function migrateGoogle(ctx: Context, user: User, googleAuth: GoogleAuth) {
  // If the user already has a googleAuth entry, we don't need to do anything.
  if (googleAuth) {
    return;
  }

  // Create a new googleAuth entry for the user.
  await ctx.entities.GoogleAuth.create({
    data: {
      user: {
        connect: { id: user.id },
      },
      googleId: googleAuth.googleId,
    },
  });
}
```

--------------------------------

### Setting Up Mock Server for Tests

Source: https://wasp.sh/llms-full-0.11.8.txt

Initialize the mock server using `mockServer` to enable mocking of Wasp queries and APIs. This should be called once per file needing mock utilities.

```javascript
import { mockServer } from "@wasp/test";

const { mockQuery, mockApi } = mockServer();
```

--------------------------------

### Example Data Migration Function for Email Auth

Source: https://wasp.sh/docs/0.12/migration-guide

A TypeScript function to migrate existing user data for Email authentication. This can be used as a starting point and copied directly into your project.

```typescript
import { type User, type EmailAuth } from "@wasp/entities";
import { type Context } from "@wasp/api";

export async function migrateEmail(ctx: Context, user: User, emailAuth: EmailAuth) {
  // If the user already has an emailAuth entry, we don't need to do anything.
  if (emailAuth) {
    return;
  }

  // Create a new emailAuth entry for the user.
  await ctx.entities.EmailAuth.create({
    data: {
      user: {
        connect: { id: user.id },
      },
      email: emailAuth.email,
      passwordHash: emailAuth.passwordHash,
      isVerified: emailAuth.isVerified,
    },
  });
}
```

--------------------------------

### Navigate to Project Directory

Source: https://wasp.sh/llms-full-0.19.txt

Change into the newly created project directory to access its files and run development commands.

```sh
cd TodoApp
```