Cli-microsoft365: Bug report: Installation of Office 365 CLI in Azure Cloud Shell fails

[alexandair]

Description

I've tried to install Office 365 CLI in Azure Cloud Shell. Installation fails with the error message " tarball data for [email protected] has been corrupted".

Installation of the beta version (2.10.0-beta.9e086a8) has worked.

Steps to reproduce

I've created the ~/.npm-global folder and change the ~/.npmrc file accordingly.

npm install -g @pnp/office365-cli # fails
npm install -g @pnp/office365-cli@next # works 

Expected result

npm install -g @pnp/office365-cli installs the stable version of Office 365 CLI.

Actual result

Installation fails with the error message " tarball data for [email protected] has been corrupted",

Environment

Azure Cloud Shell (ACC_VERSION=master_20200424.2)

[waldekmastykarz]

Thanks for reporting. Is Azure Cloud Shell the only place where the installation fails? Could be something temporary being wrong with npm?

[alexandair]

I haven't tried anywhere else. I've tried 4 times in a period of 30 minutes, and then I decided to install a beta and that worked.

Btw, installation, by default, asks for an elevated user. That's not possible in Cloud Shell, or some people would like to install it as a standard user. Those steps should be documented in the installation section of the docs.

[waldekmastykarz]

Good suggestion! Our docs follow the typical setup for installing Node.js executables, but like you mentioned, things work slightly different in Azure Cloud Shell. We'll create a separate issue for extending the docs. Meanwhile, we'll also investigate the issue you mentioned regarding installing the latest version of the CLI and see if we can find out more. Once again, thank you for reporting it 👍

[waldekmastykarz]

Does Azure Cloud Shell use any kind of npm cache? I've tried reproducing the issue you mentioend locally, but can't. Despite clearing the local cache, the latest version of the CLI installs just fine. Both versions, @latest and @next use the same version of typescript with identical package hash so that theoretically eliminates issues with npm. Do you have any kind of log that we could use to get some more information about what's going wrong?

[alexandair]

I have very limited experience with npm (practically just following the docs; if it works, I'm a happy camper, if it doesn't I google for a solution). I will ask the Cloud Shell team about the npm cache.

[waldekmastykarz]

Awesome! Appreciate your help with finding out what's wrong ❤️

[edyoung]

npm i @pnp/office365-cli

Worked fine for me. I haven't tried repointing npm_global.

[alexandair]

From a user perspective, what is the difference between installing it globally and locally?

[garrytrinder]

From https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/

In npm 1.0, there are two ways to install things:

1. globally —- This drops modules in {prefix}/lib/node_modules, and puts executable files in {prefix}/bin, where {prefix} is usually something like /usr/local. It also installs man pages in {prefix}/share/man, if they’re supplied.
2. locally —- This installs your package in the current working directory. Node modules go in ./node_modules, executables go in ./node_modules/.bin/, and man pages aren’t installed at all.

[alexandair]

I've found a similar doc. And, from a user perspective the only difference is will I get man pages or not.
Why should I care where are files installed?

I also found a note saying "if you will use an npm package at the command line, install it globally".

It's obviously easier to install it locally in Cloud Shell (no need for an additional folder, setting up a prefix).

[waldekmastykarz]

In most cases you'd install Node.js-based executables globally. After all, you want to be able to run them from any directory. Local installations are typical for packages used in projects. If you install an executable locally, the entrypoint is not registered with the system, which is why you need to run it by calling ./node_modules/bin/exec. So while a local installation for an executable is possible, it's very rare.

That said, Cloud Shell is different because you don't own the system which is why you either need to use workarounds to get it installed globally or need to install it locally. If we can make it easier for folks to use the Office 365 CLI in Cloud Shell we definitely should.

[waldekmastykarz]

Hey @alexandair is your question answered or is there anything else that we could clarify?

[alexandair]

@waldekmastykarz You can close it. Thank you.

[waldekmastykarz]

Thank you for confirming all is well 👍