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
. We refer to the workspace you develop in as your local environment; the workspace you deploy your app to is your deployed environment.
You don't have to deploy your app. In fact, 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 your local environment during slack run
as a development environment. We even append the string (local)
to the end of your app's name when running in this context.
When you execute slack run
from the root directory of a project, the CLI will start a local development server and establish a connection to the (local)
version of your app in your workspace. Check that your CLI is logged in to the desired workspace by running slack auth list
.
To start 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.
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 (local)
), as well as a deployed version.
β¨ For more information about link triggers, check out access controls for developers.
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.
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.
Have 2 minutes to provide some feedback?
We'd love to hear about your experience building modular Slack apps. Please complete our short survey so we can use your feedback to improve.