Local development

As you're developing your Run On Slack app, you can see your changes propagated to your workspace in real-time by using slack run.

Actually, you might never need to slack deploy — maybe there's something simple you want to do, just one single time, or only when you need to — you can use slack run for that.

But otherwise, you should think of the environment during slack run as a development environment. We even append the string (dev) to the end of your app's name when running in this context.

Using slack run

When you execute slack run from the root directory of a Run On Slack project, the CLI will start a local development server and establish a connection to the (dev) version of your app in your workspace.

To turn on the local development server, use the run command:

$ slack run

You'll know your development server is ready when your terminal says the following:

Connected, awaiting events

To turn off the development server, use Ctrl+c.

Note that while you're working in local development mode, no one else will be able to see or interact with your app except for you.

Creating link triggers in local development

Link triggers are unique to each installed version of your app. This means that their "shortcut URLs" will be different across each workspace, as well as between locally run and deployed apps.

When creating a trigger, you must select the workspace that you'd like to create the trigger in. Each workspace has a development version (denoted by (dev)), as well as a deployed version.

✨ For more information about link triggers, check out access controls for developers.

Listing triggers

When developing locally, you can list the triggers that are associated with your app's workflows by adding --show-triggers to the slack run command, like this:

$ slack run --show-triggers

If your app has any triggers created within that development environment, they'll be listed in your terminal. If you only created triggers within a production environment using slack deploy, they will not appear.

Creating triggers with slack run

If you have not used slack triggers create to create a trigger prior to running slack run, you will receive a prompt in the CLI to do so.

Let's say you've created a Slack app and hit it with a slack run without first creating a trigger. The CLI will first ask you which workspace you'd like to run in, and then will prompt you to choose a trigger definition file. If you choose a file, the trigger will be created and the app will run. If you do not choose a trigger definition file or if you do not yet have one created, a trigger will obviously not be created. No worries either way, your app will still continue with the run operation.

Using environment variables

When developing locally, environment variables present in a .env file at the root of your project will be made available to your custom functions via the env context property.

For example, given the following .env file:

MY_ENV_VAR=asdf1234

We can retrieve the MY_ENV_VAR environment variable from a custom Slack function like this:

// functions/my_function.ts
import { DefineFunction, SlackFunction } from "deno-slack-sdk/mod.ts";

const MyFunctionDefinition = DefineFunction({
  callback_id: "my_function",
  title: "my function",
  source_file: "functions/my_function.ts",
  input_parameters: { properties: {}, required: [] },
  output_parameters: { properties: {}, required: [] },
});

export default SlackFunction(MyFunctionDefinition, ({ env }) => {
  const myEnvVar = env["MY_ENV_VAR"];
  // ...
  return { outputs: {} };
});

When you are ready to deploy your application to production, use env add to set environment variables; the .env will not be used when you run slack deploy.

For the above example, we could run the following before deploying our app:

slack env add MY_ENV_VAR asdf1234

Note: if your token contains non-alphanumeric characters, wrap it in quotes like this:

slack env add MY_ENV_VAR "asdf-1234"

Environment variables added with var add will be made available to your deployed app's custom functions via the env context property.

Your environment variables are always encrypted before being stored on our servers, and will be automatically decrypted when you use them—including when listing environment variables with slack var list.

Note that changes to your .env file will be reflected when you restart your local development server.