amplify-cli: amplify init "type of app" doesn't actually allow selection Windows 10
Do you want to request a feature or report a bug? Bug
What is the current behavior? When I do amplify init, it asks the first question about editor and I am able to select an editor. The next question about type of app I don’t have a chance to answer. Note below that it looks like I picked javascript, but actually I just got my os prompt back
PS C:\Users\bradt\Documents\cs\react\my-amplify-app> amplify init
Note: It is recommended to run this command from the root of your app directory
? Choose your default editor: Visual Studio Code
? Choose the type of app that you're building (Use arrow keys)
android
ios
> javascript
PS C:\Users\bradt\Documents\cs\react\my-amplify-app>
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
- Run amplify init
- Select editor
- Notice no change to select type of app
What is the expected behavior? Should be able to select app type
Which versions of Amplify CLI, and which OS are affected by this issue? Did this work in previous versions?
Windows 10, latest version of Amplify CLI that gets installed (0.1.14)
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 7
- Comments: 28 (15 by maintainers)
I finally got it working, just leaving this here in case it helps anyone else.
Using WSL did not make a difference. I also tried using several different command windows and shells (Powershell, cmd, cmder, Consolez, bash) and none if it made a difference. I also tried running a linux terminal using docker (docker -it) and running amplify init in there, and still I would have the exact same issue.
How I eventually got it working is that I switched from using yarn to npm. Using npm with a global install of @aws-amplify/cli works now, and I can choose the app type on the second step of amplify init.
We published a new version of the CLI to npm, version -> 0.1.32 with fixes for windows. Feel free to re-open the issue if the problem still persists.
@attilah We have an issue open with our dependent CLI framework for making it work on windows natively and are actively working with them to get the fix out. Until then we recommend using WSL.