Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Other Installer options for the CLI #2561

kaustavghosh06 opened this issue Oct 11, 2019 · 8 comments


Copy link

@kaustavghosh06 kaustavghosh06 commented Oct 11, 2019

Currently, the CLI uses npm as a package manager and requires users of the CLI to install npm with node version > 8.2 for successful installation of the CLI.
This RFC is to gauge community interest around the CLI being published to other package managers if there's a disinterest in installing the CLI via npm or yarn.

Some of the options which we're considering are the following:

  • brew for macOS
  • Windows 64/32 bit installers
  • snap for Ubuntu 16+
  • curl for installing the CLI as a tarbal via a HTTP request

Please comment on this thread if you've faced issues with npm when installing the CLI and if you think adding additional installers would smoothen out the CLI installation process for you or your team.


This comment has been minimized.

Copy link

@undefobj undefobj commented Oct 11, 2019


This comment has been minimized.

Copy link

@undefobj undefobj commented Oct 11, 2019

Some additional options we would like feedback on:

  • Gradle dependencies and installation
  • Cocoapods hooks & build phases

This comment has been minimized.

Copy link

@mtliendo mtliendo commented Oct 11, 2019

Is there a separate thread where users were having issues with npm? Perhaps it's the bubble I'm in, though I just figured that since Amplify was a web/mobile framework, that most users would be comfortable using npm.

I suspect the native crowd (swift, java) devs may be the driving factor?

Thanks again for all the hard work on the package, apologies that I'm a bit off topic.


This comment has been minimized.

Copy link

@chrisdag chrisdag commented Oct 11, 2019

Some of my largest AWS clients run "hard shell" private VPCs where internet access is blocked by default and 99% of subnets are private. All communication to the external world, when allowed passes through SSL decrypting firewalls for analysis.

We mirror software repositories internally for simple things like Perl CPAN and R CRAN but the new generation of package managers used by modern frameworks (like npm) have client-server communication requirements that make a static private internal mirror effectively impossible.

We've since deployed some Nexus Repository Managers to handle the new generation of package managers which works ok. NPM is hosted here.

So please consider this a +1 vote for a simple tarball install method that we could host internally on a private HTTP mirror.

This is a minor side digression into my constant rant that most of the AWS best practices, evangelist outreach materials/talks along with nearly all of the published AWS design and deploy patterns just inherently assume that unrestricted internet egress is always available and always allowed. AWS Parallelcuster ruined my day last week when their newest release started trying to download crap from github instead of pulling from their regional S3 buckets or custom ami directly.


This comment has been minimized.

Copy link

@ILAsoft ILAsoft commented Oct 11, 2019

I appreciate clean and easy options that are standard in the industry and work the same way across multiple OSes, so while brew is great otherwise, I really like that NPM is the supported option and would prefer for it to stay (at least as one of the main supported options). Having said that, and ss mentioned above, tar would be another great generic one to have as a fallback for everyone.

P.S. Thank you for opening this feedback process to the public - love the transparency!!


This comment has been minimized.

Copy link

@jkeys-ecg-nmsu jkeys-ecg-nmsu commented Oct 12, 2019

@mtliendo well one thing that sucks about npm install is that it's not an idempotent operation. I should not have to run npm install, get a single package that fails to install for some reason, manually install that package, re-run npm install, etc. until I get a working node_modules. And then sometimes you'll run npm install, get zero errors, run it again, and get updated or removed packages.

That being said, @kaustavghosh06 your OP implies that installing Amplify CLI, SDK and the Amp component libraries can currently be installed with yarn. If so this is an undocumented feature, or maybe requires a more advanced understanding of yarn. (Does yarn synchronize with an npm mirror, meaning all npm packages can be installed by yarn by default?) Either way yarn support should be documented.


This comment has been minimized.

Copy link

@mtliendo mtliendo commented Oct 12, 2019

I get your perspective--and I apologize in advance for the assumptions I'm going to make, though I hear feedback like that when I'm teaching devs that are newer to JS, specifically the JS package managers.

A couple of things to note about npm:

  • When installing packages, some packages may log errors in the console, but this could be for a variety of reasons but the case shouldn't be that it installs others except for that one package. For example, a common error that pops up for Windows users is something about node-gyp. Though that's an error that's thrown because it's doing a check for linux machines (it sucks that it shows an error), but the package execution continues

  • If having to manually add packages (relating to amplify), then I would file an issue so we can get some feedback and troubleshoot. That definitely shouldn't be happening.

  • npm (as opposed to yarn) will audit packages for security vulnerabilities. While those packages can be manually updated as a way to resolve the vulnerabilities, it's best to leave that to the Amplify team since an updated package might introduce breaking changes.

Regarding yarn:

  • The amplify framework can definitely be used with yarn 😊
    • npm i -g yarn will install the command, in which case as long as your project is initialized with yarn (specifically, a yarn.lock file exists) then amplify will can pick it up to install its dependencies
  • I agree, the above statement could be documented (easy Hacktoberfest PR if you're interested 😇)
  • To answer your last question, the yarn registry used to just point directly to the npm registry, but I think that changed in the past year or so. Either way, you can use yarn or npm to manage packages. Personally I prefer npm for the package auditing, but yarn also has some nifty features as well.

Hope that helps, or at least demystifies some things! Happy coding!


This comment has been minimized.

Copy link

@leantide leantide commented Oct 24, 2019

Just on a related note, on Mac there was an issue installing amplify-cli via npm if node was installed via brew. After installing node via nvm (which by the way I installed via brew), I no longer had issues installing amplify-cli via npm.

So brew -> nvm -> node -> npm -> amplify-cli. Haha!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
8 participants
You can’t perform that action at this time.