Developing Slack apps with the Slack CLI has been a focused feature of workflow apps, and we’re now excited to bring support to apps using the Bolt frameworks with the Slack CLI v3.0.0 release!
The Bolt frameworks have been a popular choice for developing Slack apps, with conveniences including Socket Mode for establishing quick connections and built-in OAuth support for authenticating installations.
Setting up and configuring those features has been encouraged with the pages of app settings for most apps. This is great for discovering new features and exploring options such as distribution! One point during app development that proved difficult for many, however, was keeping track of these changes in a programmatic fashion.
Introductions of API methods for the app manifest made scripting certain changes possible, but managing authentications and access to application settings still remained an exercise left for the developer.
The Slack CLI v3.0.0 release support for Bolt apps aims to make creating new apps and managing existing apps more simple. This release highlights our collection of sample apps in various languages, including Java, JavaScript, Python, and TypeScript, to start building with best practices while using all of the latest features!
We’ve streamlined development with a setup that encourages separate apps to experiment with as well as providing automatic updates of changes to the app manifest. When paired with a developer sandbox and token management happening behind the scenes, iterating on a Slack app becomes faster with more happening from the command line.
Getting started with Slack CLI and Bolt
The entire app lifecycle, from create to run to deploy, then re-deploy and re-deploy, was considered in this release and we hope some part is useful in future developments!
Starting from a clean path for development, we revamped the slack create command options to showcase the latest apps and samples for immediate experimentation:
This new example app is configured with runtime dependencies needed for Slack CLI development, but existing Bolt apps can use the slack init command for these same setups.
Starting the app with the slack run command uses the app manifest to create and install the app to a selected team before connecting with Socket Mode. The code generated earlier is now being used to run this app, and you can update the app manifest without interruption:
After enough code changes are made, the slack deploy command can then be configured with a script or command to be called after similar manifest updates and app re-installations are made for the selected app.
Customizations to Slack CLI hooks – a protocol the Slack CLI uses to communicate with the different Bolt frameworks, but more on this below – brings exciting possibilities to app development and deployment with the above advantages!
For example, apps running from a Heroku Git branch can push the latest changes while also making changes to the app manifest:
Taking these commands to a familiar CI/CD service or related script can also be done with a service token retrieved using the slack auth token command.
Communicating with the SDKs
Introducing support for new runtimes with the Slack CLI meant revisiting how information was sent to and received from the application frameworks.
To do this, we’ve implemented various scripts for each runtime that the Slack CLI calls at certain points when running a command. This “hook” approach gives each SDK a place to execute application or runtime specific logic, such as diagnosing errors with the slack doctor command and running the app with the slack run command.
For example, apps built with Bolt for JavaScript include runtime information as part of this doctor hook:
Getting all of the hooks
.slack/hooks.json file within a project and the response from the included get-hooks script is used to initialize the capabilities available to the Slack CLI within a project.
Customizing different scripts
Certain customizations are sometimes needed and encouraged to match specific project setups too.
Since the Slack CLI expects certain responses for each hook, hook scripts can be adjusted however desired. We’re excited to share more details about this soon.
The slack deploy command used above demonstrated a custom “deploy” hook. You can see other overrides in this example:
Differences with this version
Ongoing iterations and code changes made this release possible!
Since the earliest release, we’ve adapted our hook protocol to parse responses according to random “message boundaries” that stream SDK logs to standard outputs while capturing the hook response.
These project specific responses can be revealed in a verbose mode with the following command:
We’ve also embraced the Go strategies of treating errors as values, surfacing these responses in erroring cases from either the project hooks or a Slack API response.
While debugging failing cases often isn’t fun, we hope this makes finding the cause of problems ever so much faster.
Learn more
We have pages of documentation to help along the way. https://docs.slack.dev/
Constant iteration from feedback being shared has also been invaluable in adding to these developments. We’re so thankful for what’s written in and hope to catch you in the Slack Community or on GitHub sometime soon!
Or, share feedback beforehand with the following command 💌
