git dependencies don't work with the global switch

(Brandon Moore) #1

What I Wanted to Do

Install cogear for static site development by following the directions of running npm install cogear -g

What Happened Instead

  • First Attempt (Arch Linux) *

On my default system, I ran the command as my user, and found that I needed root privileges which seemed normal for Arch. When running as root, I received the following error:

root@stretch:/home/vagrant# npm install -g cogear
npm WARN deprecated postcss-cssnext@3.1.0: 'postcss-cssnext' has been deprecated in favor of 'postcss-preset-env'. Read more at https://moox.io/blog/deprecating-cssnext/
npm ERR! code 128
npm ERR! Command failed: git clone --mirror -q https://github.com/weixin/node-sftp-deploy.git /root/.npm/_cacache/tmp/git-clone-3bd6e515/.git
npm ERR! fatal: could not create leading directories of '/root/.npm/_cacache/tmp/git-clone-3bd6e515/.git'
npm ERR! 

This appears to relate to the cogear dependency line: "node-sftp-deploy": "https://github.com/weixin/node-sftp-deploy.git",. Please note that while this line doesn’t follow npm’s rule for git urls as dependencies, it is being interpreted as a git url according to these lines of the log file:

270 silly fetchPackageMetaData error for node-sftp-deploy@git+https://github.com/weixin/node-sftp-deploy.git Command failed: git clone --mirror -q http
s://github.com/weixin/node-sftp-deploy.git /root/.npm/_cacache/tmp/git-clone-eea31623/.git
270 silly fetchPackageMetaData fatal: could not create leading directories of '/root/.npm/_cacache/tmp/git-clone-eea31623/.git'
271 timing stage:rollbackFailedOptional Completed in 0ms
272 timing stage:runTopLevelLifecycles Completed in 600ms
273 verbose stack Error: Command failed: git clone --mirror -q https://github.com/weixin/node-sftp-deploy.git /root/.npm/_cacache/tmp/git-clone-eea3162
3/.git

I decided to try a Debian Vagrant Box.

  • Second Attempt (Debian Vagrant Box) *

In the vagrant box (which all details below relate to), I attempted to install the package as root via npm install cogear -g. I received the same error as I had on my first attempt. This confirmed that the problem wasn’t distro-specific.

Reproduction Steps

If using Vagrant, use this Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "debian/stretch64"
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get install -y curl git
    curl -sL https://deb.nodesource.com/setup_11.x | sudo -E bash -
    apt-get install -y nodejs
    npm install cogear -g
  SHELL
end

Otherwise, in a Fresh Nodejs install, with global packages saving to root like they default to, attempt to install cogear via npm install cogear -g.

Platform Info

$ npm --versions
{ npm: '6.7.0',
  ares: '1.15.0',
  brotli: '1.0.7',
  cldr: '34.0',
  http_parser: '2.8.0',
  icu: '63.1',
  llhttp: '1.1.1',
  modules: '67',
  napi: '4',
  nghttp2: '1.34.0',
  node: '11.13.0',
  openssl: '1.1.1b',
  tz: '2018e',
  unicode: '11.0',
  uv: '1.27.0',
  v8: '7.0.276.38-node.18',
  zlib: '1.2.11' }
<!-- paste output here -->
$ node -p process.platform
linux
<!-- paste output here -->

Why do I think this is an npm problem?

npm clearly recognized the dependency as a git url, and failed internally when attempting to mirror the repo. While I didn’t search for or create another package to confirm this bug, it seems clear that the dependencies are being handled by npm and not some magic code in the package.

0 Likes

(John Gee) #2

I suspect the problem is running as root rather than the git dependency as such. Some things run using sudo or as root trip up npm, which tries to keep you safer when there is potential for running arbitrary scripts with full privilege.

Try:

# npm install -g --unsafe-perm cogear

(This made a difference for me when I tried reproducing your problem on Ubuntu.)

0 Likes

(Brandon Moore) #3

I tried adding the flag unsafe-perm (both on a new Debian Vagrant box and my Arch install), but I received the same error. I’ll try again with an Ubuntu box later on.

0 Likes

(John Gee) #4

(Drat, docker vs vagrant, Linux flavours, thought they would be more similar.)

In a precious root work-around, someone needed to use config setting rather than CLI flag. Although that was with npm ci rather than npm install so again may not work for you!

0 Likes

(Brandon Moore) #5

No problem; things get confusing with all these tools. Vagrant is just being used to make a VM with VirtualBox in my case, so it should be the same as a box on baremetal for our purposes.

Unfortunately setting the config unsafe-perm changed nothing.

I went ahead and added an Ubuntu Vagrant box (actually two). The good news is that one of them works. So here are the results:

While I’m happy to have one working, I still believe this to be a bug with NPM or at the very least an offputting experience for users.

0 Likes

(John Gee) #6

Whacko! Thanks for testing multiple environments, and identifying a difference too. (And I was not claiming not a bug, but I do like to find a work-around.)

0 Likes

(Brandon Moore) #7

Sorry if my tone came off as hostile at all, shadowspawn. I greatly appreciate your help.

Since I have a work-around now (i.e. using another Vagrant box), I might not be as involved in this bug report going forward. I didn’t think that you were shutting this down as a possible bug. I merely wanted to emphasize that although I have a work-around, this is still an active bug report that could use further investigation.

1 Like

(John Gee) #8

No problem, and I was not concerned by your tone, thanks. I was concerned my own tone might have seemed dismissive of there being a “bug” (but I ended up sounding defensive rather than supportive!).

Thanks again for your contributions.

1 Like