A bunch more doc updates after feedback

Author: ericallam

docs/config/config-file.mdx

@@ -105,7 +105,7 @@ Some ones we recommend:
 
 ## Runtime
 
-We currently only official support the `node` runtime, but you can try our expirimental `bun` runtime by setting the `runtime` option in your config file:
+We currently only officially support the `node` runtime, but you can try our experimental `bun` runtime by setting the `runtime` option in your config file:
 
 ```ts trigger.config.ts
 import { defineConfig } from "@trigger.dev/sdk/v3";
@@ -453,7 +453,11 @@ These environment variables are only used during the build process and are not e
 
 </Note>
 
-#### `audioWaveform`
+#### syncEnvVars
+
+The `syncEnvVars` build extension replaces the deprecated `resolveEnvVars` export. Check out our [syncEnvVars documentation](/deploy-environment-variables#sync-env-vars-from-another-service) for more information.
+
+#### audioWaveform
 
 Previously, we installed [Audio Waveform](https://github.com/bbc/audiowaveform) in the build image. That's been moved to a build extension:
 
@@ -469,7 +473,7 @@ export default defineConfig({
 });
 ```
 
-#### `ffmpeg`
+#### ffmpeg
 
 You can add the `ffmpeg` build extension to your build process:
 
@@ -528,7 +532,7 @@ export default defineConfig({
 });
 ```
 
-#### `aptGet`
+#### aptGet
 
 You can install system packages into the deployed image using using the `aptGet` extension:
 

docs/deploy-environment-variables.mdx

@@ -74,8 +74,8 @@ You can use our SDK to get and manipulate environment variables. You can also ea
 
 We have a complete set of SDK functions (and REST API) you can use to directly manipulate environment variables.
 
-| Function                                              | Description                                                 |
-| ----------------------------------------------------- | ----------------------------------------------------------- |
+| Function                                           | Description                                                 |
+| -------------------------------------------------- | ----------------------------------------------------------- |
 | [envvars.list()](/management/envvars/list)         | List all environment variables                              |
 | [envvars.upload()](/management/envvars/import)     | Upload multiple env vars. You can override existing values. |
 | [envvars.create()](/management/envvars/create)     | Create a new environment variable                           |
@@ -85,93 +85,91 @@ We have a complete set of SDK functions (and REST API) you can use to directly m
 
 ### Sync env vars from another service
 
-You could use the SDK functions above but it's much easier to use our `resolveEnvVars` function in your `trigger.config` file.
+You could use the SDK functions above but it's much easier to use our `syncEnvVars` build extension in your `trigger.config` file.
 
-In this example we're using env vars from [Infisical](https://infisical.com).
+<Note>
+  To use the `syncEnvVars` build extension, you should first install the `@trigger.dev/build`
+  package into your devDependencies.
+</Note>
 
-```ts /trigger.config.ts
-import type { TriggerConfig, ResolveEnvironmentVariablesFunction } from "@trigger.dev/sdk/v3";
-
-//This runs when you run the deploy command or the dev command
-export const resolveEnvVars: ResolveEnvironmentVariablesFunction = async ({
-  //the project ref (starting with "proj_")
-  projectRef,
-  //any existing env vars from a .env file or Trigger.dev
-  env,
-  //"dev", "staging", or "prod"
-  environment,
-}) => {
-  //the existing environment variables from Trigger.dev (or your local .env file)
-  if (env.INFISICAL_CLIENT_ID === undefined || env.INFISICAL_CLIENT_SECRET === undefined) {
-    //returning undefined won't modify the existing env vars
-    return;
-  }
-
-  const client = new InfisicalClient({
-    clientId: env.INFISICAL_CLIENT_ID,
-    clientSecret: env.INFISICAL_CLIENT_SECRET,
-  });
-
-  const secrets = await client.listSecrets({
-    environment,
-    projectId: env.INFISICAL_PROJECT_ID!,
-  });
-
-  return {
-    variables: secrets.map((secret) => ({
-      name: secret.secretKey,
-      value: secret.secretValue,
-    })),
-    // this defaults to true
-    // override: true,
-  };
-};
+In this example we're using env vars from [Infisical](https://infisical.com).
 
-//the rest of your config file
-export const config: TriggerConfig = {
-  project: "proj_1234567890",
-  //etc
-};
+```ts trigger.config.ts
+import { defineConfig } from "@trigger.dev/sdk/v3";
+import { syncEnvVars } from "@trigger.dev/build/extensions/core";
+import { InfisicalClient } from "@infisical/sdk";
+
+export default defineConfig({
+  build: {
+    extensions: [
+      syncEnvVars(async (ctx) => {
+        const client = new InfisicalClient({
+          clientId: process.env.INFISICAL_CLIENT_ID,
+          clientSecret: process.env.INFISICAL_CLIENT_SECRET,
+        });
+
+        const secrets = await client.listSecrets({
+          environment: ctx.environment,
+          projectId: process.env.INFISICAL_PROJECT_ID!,
+        });
+
+        return secrets.map((secret) => ({
+          name: secret.secretKey,
+          value: secret.secretValue,
+        }));
+      }),
+    ],
+  },
+});
 ```
 
-#### Local development
-
-When you [develop locally](/cli-dev) `resolveEnvVars()` will inject the env vars from [Infisical](https://infisical.com) into your local `process.env`.
-
 #### Deploy
 
 When you run the [CLI deploy command](/cli-deploy) directly or using [GitHub Actions](/github-actions) it will sync the environment variables from [Infisical](https://infisical.com) to Trigger.dev. This means they'll appear on the Environment Variables page so you can confirm that it's worked.
 
 This means that you need to redeploy your Trigger.dev tasks if you change the environment variables in [Infisical](https://infisical.com).
 
-### The variables return type
+<Note>
+  The `process.env.INFISICAL_CLIENT_ID`, `process.env.INFISICAL_CLIENT_SECRET` and
+  `process.env.INFISICAL_PROJECT_ID` will need to be supplied to the `deploy` CLI command. You can
+  do this via the `--env-file .env` flag or by setting them as environment variables in your
+  terminal.
+</Note>
+
+#### Dev
 
-You can return `variables` as an object with string keys and values, or an array of names + values.
+`syncEnvVars` does not have any effect when running the `dev` command locally. If you want to inject environment variables from another service into your local environment you can do so via a `.env` file or just supplying them as environment variables in your terminal. Most services will have a CLI tool that allows you to run a command with environment variables set:
+
+```sh
+infisical run -- npx trigger.dev@latest dev
+```
+
+Any environment variables set in the CLI command will be available to your local Trigger.dev tasks.
+
+### The syncEnvVars callback return type
+
+You can return env vars as an object with string keys and values, or an array of names + values.
 
 ```ts
 return {
-  variables: {
-    MY_ENV_VAR: "my value",
-    MY_OTHER_ENV_VAR: "my other value",
-  },
+  MY_ENV_VAR: "my value",
+  MY_OTHER_ENV_VAR: "my other value",
 };
 ```
 
 or
 
 ```ts
-return {
-  variables: [
-    {
-      name: "MY_ENV_VAR",
-      value: "my value",
-    },
-    {
-      name: "MY_OTHER_ENV_VAR",
-      value: "my other value",
-    },
-  ],
-};
+return [
+  {
+    name: "MY_ENV_VAR",
+    value: "my value",
+  },
+  {
+    name: "MY_OTHER_ENV_VAR",
+    value: "my other value",
+  },
+];
 ```
 
 This should mean that for most secret services you won't need to convert the data into a different format.
@@ -184,11 +182,11 @@ Securely pass a Google credential JSON file to your Trigger.dev task using envir
 
 <Step title="Convert the Google credential file to base64">
 
-  In your terminal, run the following command and copy the resulting base64 string:
+In your terminal, run the following command and copy the resulting base64 string:
 
-  ```
-  base64 path/to/your/service-account-file.json
-  ```
+```
+base64 path/to/your/service-account-file.json
+```
 
 </Step>
 
@@ -207,13 +205,15 @@ GOOGLE_CREDENTIALS_BASE64="<your base64 string>"
 Add the following code to your Trigger.dev task:
 
 ```ts
-import { google } from 'googleapis';
+import { google } from "googleapis";
 
-const credentials = JSON.parse(Buffer.from(process.env.GOOGLE_CREDENTIALS_BASE64, 'base64').toString('utf8'));
+const credentials = JSON.parse(
+  Buffer.from(process.env.GOOGLE_CREDENTIALS_BASE64, "base64").toString("utf8")
+);
 
 const auth = new google.auth.GoogleAuth({
   credentials,
-  scopes: ['https://www.googleapis.com/auth/cloud-platform'],
+  scopes: ["https://www.googleapis.com/auth/cloud-platform"],
 });
 
 const client = await auth.getClient();
@@ -227,4 +227,4 @@ You can now use the `client` object to make authenticated requests to Google API
 
 </Step>
 
-</Steps>
+</Steps>

docs/github-actions.mdx

@@ -99,14 +99,14 @@ If you already have a GitHub action file, you can just add the final step "🚀
 
 ## Version pinning
 
-The CLI and `@trigger.dev/*` package versions need to be in sync, otherwise there will be errors and unpredictable behavior. Hence, the `deploy` command will automatically fail during CI on any version mismatches.
+The CLI and `@trigger.dev/*` package versions need to be in sync with the `trigger.dev` CLI, otherwise there will be errors and unpredictable behavior. Hence, the `deploy` command will automatically fail during CI on any version mismatches.
 Tip: add the deploy command to your `package.json` file to keep versions managed in the same place. For example:
 
 ```json
 {
   "scripts": {
-    "deploy:trigger-prod": "npx [email protected]-beta.34 deploy",
-    "deploy:trigger": "npx [email protected]-beta.34 deploy --env staging"
+    "deploy:trigger-prod": "npx [email protected] deploy",
+    "deploy:trigger": "npx [email protected] deploy --env staging"
   }
 }
 ```

docs/guides/bun.mdx

@@ -0,0 +1,113 @@
+---
+title: "Bun guide"
+sidebarTitle: "Bun"
+description: "This guide will show you how to setup Trigger.dev with Bun"
+icon: "js"
+---
+
+import Prerequisites from "/snippets/framework-prerequisites.mdx";
+import CliRunTestStep from "/snippets/step-run-test.mdx";
+import CliViewRunStep from "/snippets/step-view-run.mdx";
+
+We now have experimental support for Bun. This guide will show you have to setup Trigger.dev in your existing Bun project, test an example task, and view the run.
+
+<Warn>
+  The trigger.dev CLI does not yet support Bun. So you will need to run the CLI using Node.js. But
+  Bun will still be used to execute your tasks, even in the `dev` environment.
+</Warn>
+
+<Prerequisites framework="Bun" />
+
+## Initial setup
+
+<Steps>
+  <Step title="Run the CLI `init` command">
+
+The easiest way to get started is to use the CLI. It will add Trigger.dev to your existing project, create a `/trigger` folder and give you an example task.
+
+Run this command in the root of your project to get started:
+
+<CodeGroup>
+
+```bash npm
+npx trigger.dev@latest init --runtime bun
+```
+
+```bash pnpm
+pnpm dlx trigger.dev@latest init --runtime bun
+```
+
+```bash yarn
+yarn dlx trigger.dev@latest init --runtime bun
+```
+
+</CodeGroup>
+
+It will do a few things:
+
+1. Log you into the CLI if you're not already logged in.
+2. Create a `trigger.config.ts` file in the root of your project.
+3. Ask where you'd like to create the `/trigger` directory.
+4. Create the `/src/trigger` directory with an example task, `/src/trigger/example.[ts/js]`.
+
+Install the "Hello World" example task when prompted. We'll use this task to test the setup.
+
+</Step>
+
+  <Step title="Update example.ts to use Bun">
+
+    Open the `/src/trigger/example.ts` file and replace the contents with the following:
+
+    ```ts example.ts
+    import { Database } from "bun:sqlite";
+    import { task } from "@trigger.dev/sdk/v3";
+
+    export const bunTask = task({
+      id: "bun-task",
+      run: async (payload: { query: string }) => {
+        const db = new Database(":memory:");
+        const query = db.query("select 'Hello world' as message;");
+        console.log(query.get()); // => { message: "Hello world" }
+
+        return {
+          message: "Query executed",
+        };
+      },
+    });
+
+    ```
+
+  </Step>
+
+  <Step title="Run the CLI `dev` command">
+
+The CLI `dev` command runs a server for your tasks. It watches for changes in your `/trigger` directory and communicates with the Trigger.dev platform to register your tasks, perform runs, and send data back and forth.
+
+It can also update your `@trigger.dev/*` packages to prevent version mismatches and failed deploys. You will always be prompted first.
+
+<CodeGroup>
+
+```bash npm
+npx trigger.dev@latest dev
+```
+
+```bash pnpm
+pnpm dlx trigger.dev@latest dev
+```
+
+```bash yarn
+yarn dlx trigger.dev@latest dev
+```
+
+</CodeGroup>
+
+</Step>
+
+<CliRunTestStep />
+<CliViewRunStep />
+
+</Steps>
+
+## Known issues
+
+- Certain OpenTelemetry instrumentation will not work with Bun, because Bun does not support Node's `register` hook. This means that some libraries that rely on this hook will not work with Bun.