Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Attempting to run
amplify auth add
returns a "Command not found" error, with the suggestion:
amplify auth <subcommands>
add [......]
Attempting to run
amplify add auth (inverting 'auth' and 'add') produces the same outcome
On the off chance, I also tried
amplify add authentication,
but this triggered the analytics flow. Analytics seems to be the default? (Running amplify add anything also triggered the analytics flow).
Taking a brief look at the code, it looks like Auth is structured very differently to the other modules. There is no "auth/add.js" file in the commands folder, but rather, the add command is listed in the index.js two levels up. (The index.js also looks substantially different to other commands). It seems like maybe it got missed in a code restructure?
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
See above.
What is the expected behavior?
Running amplify auth add should start the wizard process to create a cognito user store.
Which versions of Amplify CLI, and which OS are affected by this issue? Did this work in previous versions?
Amplify version: 0.1.14 (This is the first version I have used, but I _assume_ this worked previously)
Node version: 8.11.4
NPM version: 5.6.0
OS: Windows 10 (Powershell)
Hey Erica, Were you able to get amplify configure and amplify init to work on your windows machine?
Hi Kaustav,
Yes. init and configure worked fine (although it didn't pick up my .aws/ config files. I was able to copy/paste the data in where required). amplify add hosting and amplify publish also worked without issue.
Ah! Okay. Are you using windows Linux susbsystem and using the commands there? You might want to give amplify auth enable command a try and let me know if that works.
Re Linux Subsystem: I don't think so, although it has been a dev machine for some time so it's not completely out of the question that I turned it on at some point.
auth enable seems to have done the trick. Thank you! :)
I may have spoken too soon - It has created the cloudformation scripts and properties, but amplify push does not seem to recognize them. No changed resources, and after running it, there is no userpool in my profile.
Hey Erica, what does ‘amplify status’ return?
| Category | Resource name | Operation | Provider plugin |
| -------- | ------------------ | --------- | ----------------- |
| Auth | amplifytestcognito | Create | awscloudformation |
| Hosting | S3AndCloudFront | No Change | awscloudformation |
amplify push
| Category | Resource name | Operation | Provider plugin |
| -------- | ------------- | --------- | --------------- |? Are you sure you want to continue? true
- Updating resources in the cloud. This may take a few minutes...
√ All resources are updated in the cloud
Okay. So the auth resource has been created locally. What happens when you do an ‘amplify push’? It should ideally create the CloudFormation stack and provision the auth resources.
See above ^^ (I beat you by ~1 minute)
Hey Erica, we’re seeing some anomalous behavior on windows due to the filesystem. We’ll be figuring out a solution in the next couple of days and get back to you.
Hey guys, so I tried using the CLI with the Windows Linux subsystem(WSL) on windows and it works great. We have updated our main README as well with the following. Highly encourage using the WSL for your Amplify development.
If you're using Windows, the CLI currently supports [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
In the meanwhile, we're trying to figure out the root cause of the erroneous behavior of the CLI with the windows filesystem.
Thanks Kaustav. Could you point me to the part of the code which is generating the list of candidates in amplify push? I can try a few things on my local machine this evening.
I have a quick workaround, but not a proper solution.
Based on my quick look, I don't think this is a filesystem issue, rather a bug in gluegun.
When I run amplify push, it should be hitting the src\commands\push.js command object. According to the gluegun docs, plugins in src directory should be taking priority. For some reason though, it's got its load order confused and is instead running the amplify-category-function\commands\push.js. (They both have "name: 'push'".) The end result is that it ignores the auth elements in its status check, because the category doesn't match. ('auth' !== 'function')
The workaround for me is to add alias: pushall to the command in src\commands\push.js, and then running amplify pushall. Because that alias is unique across the codebase it doesn't have naming conflicts and runs the correct code.
And the good news is, it looks to be creating the cognito resources. Yay!
Hey Erica, awesome work figuring out the root cause :D.
I’ve gone through Glueguns codebase and in many places they’ve considered filepaths to be of format (Unix format) dir1/dir2/dir3 instead of considering dir\dir2\dir2 format which is the windows filesystem formst which is causing erroneous behavior of the CLI in windows natively. For what it’s worth I’ve filed an issue with Gluegun a few weeks back - https://github.com/infinitered/gluegun/issues/384 and hopefully we’ll have a solution for it soon.
In the meanwhile checkout @mwarger post of using wsl in native windows power shell out here - https://github.com/aws-amplify/amplify-cli/issues/13. I think it’s a great workaround.
@ericathegreat @kaustavghosh06 This reminds me of the weird behavior I saw in the log I posted to #13 -
at Command.run (C:\dev\amplify-cli\packages\amplify-category-hosting\commands\hosting\configure.js:7:39)
That is the 5th line of the stacktrace. It's trying to grab configure from the hosting plugin - does that sound right? Seems like that could be part of the cause.
EDIT: It appears that I was able to get configure to run by aliasing it to configureamplify. I still received another error after that, but I think this still confirms @ericathegreat's findings.
@mwarger Yes, that looks like the same underlying issue.
The original issue, which is amplify auth add not working, is still not fixed. Using amplify auth enable as a workaround is working but does not match the documentation.
@kavengagne. Are you running the CLI on windows? If yes, are you using the windows Linux subsystem as recommended in the main Readme?
@kaustavghosh06 I read that in the documentation. Is it a new requirement? I'm switching from awsmobile and everything has been working fine with it for a while. Im using a bash shell, not the windows command line.
@kaustavghosh06 I can confirm, it works fine on ubuntu and WSL.
hey guys i'm running the cli on WSL but still get the following error:
Cannot find module 'D:\Users\BKU\HenrySachs\AppData(Roaming)\npm\node_modules\@aws-amplify\cli\node_modules\amplify-provider-awscloudformation'
it seems to still have the wrong path format.
This issue should be fixed with the latest version of the CLI. Feel free to re-open if the problem still persists.
Still having this issue in version 0.1.24.
When I add/remove features they rarely show in the prompt after amplify push
Also amplify status gives me a list over disabled SMS services etc, instead of a list of added/removed/updated features.
I used to have v. 0.1.19 but upgraded, completely remove Amplify and tried over with v.0.1.24 - still the same issues.
I also tried to do this with Linux for Windows, Ubuntu 18 terminal. It's all working in Linux, everything adds fine and amplify status does the expected thing. I spent a lot of time yesterday setting this up, but realised I couldn't be bothered. I went back to MobileHub.
If you have a good suggestion to how I can code my application in c:/dev/app-name while editing Amplify in LfW I'll be glad, but as of now my github push/pull with ignoring specific terminal files is not good enough.
I'll use the heck out of amplify-cli when it's stable, but as for now it's not durable enough on a Windows env. There's just too many overseen bugs. If the basic Windows features gets fixed I'll report back on bugs I find.
@kaustavghosh06 Any updates on windows support with gluegun? Thanks!
Most helpful comment
Hey Erica, we’re seeing some anomalous behavior on windows due to the filesystem. We’ll be figuring out a solution in the next couple of days and get back to you.