In order to develop on the next-generation platform, your workspace must be on a paid plan.
As you're developing your next-generation 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 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 and you are logged into a Slack Enterprise Grid, you may also be asked to select a workspace within your organization to grant your app access to.
If administrators of your workspace have enabled Admin-Approved Apps, it means your app will need approval before it can be installed to your workspace.
✨ For more information about getting your app approved, check out access controls for developers.
The CLI will then start a local development server and establish a connection to the
(local) version of your app. Check that your CLI is logged in to the desired workspace by running
slack auth list.
To start the local development server, use the
$ 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
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.
If your app has any triggers created within that development environment, they'll be listed when you run
slack run. 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 tried to execute
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 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.