3 Ways to Continue Using ASK CLI 1.x With the New ASK CLI 2.x

DZone 's Guide to

3 Ways to Continue Using ASK CLI 1.x With the New ASK CLI 2.x

In this article, I will show you three different workarounds so that both ASK CLI 1.x and ASK CLI 2.x can co-exist.

· DevOps Zone ·
Free Resource

At the time of this writing, the ASK CLI 2.6.0 has just been released. Along with it comes a fair bit of breaking changes the extend of which can be seen in this migration guide

This has caused a fair bit of challenge in the community especially for developers who have multiple skills prior to ASK CLI 2.x being introduced. A lot of automation tools would also have to be rewritten and some even have no viable workarounds when using 2.x. The VSCode extension functionality that allows convenient ASK CLI support is also broken

Hence, there is a necessity to continue using ASK CLI 1.x (specifically 1.7.23) while Amazon Alexa's tech team figure out. I have spent a fair bit of time finding solutions to allow both the versions to co-exists and will share 3 ways in which you can do that here.

1. Using npm to Swap Between the Two Versions

Note: This solution is Mac/Linux specific but could apply to Windows with equivalent cmdlets Set-Alias or New-Alias.

Assuming you are using a Bash script, you basically just use aliases, as per the following code: 


You would put them in .bash_profile  in your home directory. So when you start a fresh terminal session, you can just use ask1 or ask2 when you need two swap between the two ASK CLI versions.

This method works fine for me. However, the issue is that sometime it's hard to keep track which version I am using, and I would have to run  ask --version to figure it out. Also, executing each command might take a while so you might eat up into your productivity.

2. Cloning a Source Copy of ASK CLI 2.x

This method was revealed to me by German Viscuso (@germanviscuso) via his gist.  It basically involves cloning the source code for ask cli from git into your local machine.


In the root directory of the cloned repo, you would then do the following changes to the package.json file

 "name": "ask-cli"   -->   "name": "ask-cli-x" 


 "bin" : { "ask" : "bin/ask.js" } -->  "bin" : { "askx" : "bin/ask.js" } 

After that, you will have to run npm link in the same root directory of the cloned repo. This will effectively create a global command called askx (by installing the modified package globally).

Oh, don't forget to also make sure the current ask command resolves to version 1.x. by running ask --version to check. If you want to be safe, you can run the following command, as per German's instructions.


So in the end, you will be able to run 1.x CLI by just using the ask  command and the 2.x CLI by using askx.

I've tested this and it seems to be working fine. However, German did mention that the ask  command (without the x will the standard moving forward), so this is just a temporary fix. If you start building automation tools with askx, you would then at a later point of time have to change it to ask again.

3. Using nvm to Swap Between the Two CLI

While I was testing the above workaround, I've found yet another way that might work for some of you.

For this method to work, you would have to make sure that you have installed node version manager (nvm), which can be found here

nvm basically allows you to run multiple versions of Node at the same time and allows you to switch between the versions. Now for each version of node, you can have a completely different set of node packages. So using this as a fact, you can install say node version 10 and node version 12 (as an example) 


which is the latest (10.x)


which is the latest (12.x)

and use an alias say 


You can then swap into the respective version and install the respective CLI. 




To swap between CLI 1.x ad CLI 2.x, you can just use the following respectively:




You might want to choose the two versions. For instance you might want to use for both very similar version of node which in that case you can use for instance v12.16.3 for ask2 and v12.16.2 for ask1.

Using this method is actually faster than method #1 above as you just swap the different versions and do not have to wait for the respective cli to install. You automation tool will also continue to work now and in the future.


I hope I have given you a solution that will work for you. It all depends on your preference and use cases. Hopefully this will buy you some peace of mind and time to adjust to the new ask cli 2.x. 

If you want to also know a way to get the skillid (which is being used a lot in the CLI) that works for both 1.x and 2.x, you can check out my previous article here

Let me know what you think of the workarounds. I also love to hear some ways in which you handle the upgrade.

Stay Tuned

Stay tuned for more productivity-enhancing articles regarding voice app development. If you prefer videos, I will be releasing a few sets of videos based on my just recently inspired YouTube channel. I will also try to live stream regularly on YouTube and my new Twitch channel https://twitch.tv/goldzulu. If you want to ask any question, you can also follow me on twitter @VoiceTechGuy1.

alexa skill development, amazon alexa, ask cli, command line interface, dev ops, nvm, productivity

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}