Since my latest articles on Launch Extensions, things have evolved a bit. When I look at those articles now, I feel a certain urge to delete most of them, because they are so – uhm – old.
Instead, I decided to write down an extremely streamlined version of what tools you can, nay, should use when you develop an Extension.
Setting up for Extension development hasn’t changed, per se, but you can make your life easier. Here are the steps:
- Add two environment variables to your system:
REACTOR_IO_INTEGRATION_CLIENT_SECRET— the value of which you can find in your Adobe I/O integration in the Adobe I/O console
- Create a directory and change into it
npx @adobe/reactor-scaffoldand provide answers (see Launch – Make an Extension – Reloaded for a brief example)
- Change the
nameattribute in the
extension.jsonfile! Add something at the start of the generated name that makes it clear this Extension is yours (see part 4 in 7 things I learned about making Extensions)
If you don’t know how to setup environment variables on your system, these might help: “Setting permanent environment variable using terminal” in Setting up Environment Variables in MacOS Sierra or How to set the path and environment variables in Windows for how to do that. Note that those sites are not mine. I googled, and they looked helpful.
name attribute and adding those environment variables are important! The former will avoid name clashes in the future, and the latter will allow you to more easily use the
reactor-releaser tools mentioned further down.
No changes here, but there is a new tool that you can use if you want to make sure your Extension is formally correct.
reactor-validator checks that your
extension.json file is in good shape, and that all the resources it defines do actually exist.
reactor-validator is available on github if you want to see what it does.
Uploading & Releasing
This has changed!
reactor-releaser tools have made my life so much easier!
To use them to their full potential, I suggest creating two executable files:
- On Linux / Mac:
- On Windows:
(see further down for the content of those files)
I usually add
reactor-packager to the
upload.cmd script, because I can.
When you want to upload your Extension for testing, just call
upload, then hit enter when the tool asks you which zip to upload.
And when you’re happy with your Extension, testing and all, just call
release, and the Extension will be made available in your Org.
It is very good practice to keep the sources of your Extension in some source control system, like github. And it is extremely good practice to tag the current state of your repository with the version that is currently in your
version field in
extension.json when you are done with the release.
That way, you (and others, if your github is public) can easily see the exact code that went live under that version number.
Note that making the Extension publicly available for everyone is still a process that you can kick off using the Release Public Request Form.
Appendix – the Files
If you want to have your own
release.cmd files, feel free to copy the code from below.
Make sure you replace the
api-key values with those from your Adobe I/O integration.
As a reminder, I am talking about this screen:
For Linux/Unix & Mac
#!/bin/sh npx @adobe/reactor-packager && npx @adobe/reactor-uploader --org-id=REPLACEME@AdobeOrg --tech-account-id=REPLACEME@techacct.adobe.com --api-key=REPLACEME
#!/bin/sh npx @adobe/reactor-releaser --org-id=REPLACEME@AdobeOrg --tech-account-id=REPLACEME@techacct.adobe.com --api-key=REPLACEME
@echo off npx @adobe/reactor-packager npx @adobe/reactor-uploader --org-id=REPLACEME@AdobeOrg --tech-account-id=REPLACEME@techacct.adobe.com --api-key=REPLACEME
@echo off npx @adobe/reactor-releaser --org-id=REPLACEME@AdobeOrg --tech-account-id=REPLACEME@techacct.adobe.com --api-key=REPLACEME