Winston: Cannot install on docker after 3.3.0/3.3.1

Created on 22 Jun 2020  ·  23Comments  ·  Source: winstonjs/winston

npm ERR! path git
npm ERR! code ENOENT
npm ERR! errno ENOENT
npm ERR! syscall spawn git
npm ERR! enoent Error while executing:
npm ERR! enoent undefined ls-remote -h -t ssh://[email protected]/DABH/diagnostics.git
npm ERR! enoent
npm ERR! enoent
npm ERR! enoent spawn git ENOENT
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

Looks like this is related with #1813, and it still happens when trying to install on docker with nodejs 12.

Most helpful comment

All, v3.3.2 has been released, this downloads the forked diagnostics dependency from NPM not GitHub so it should work for you. Please feel free to confirm or deny. Thanks!

All 23 comments

Same problem here, but not only in docker. I can't npm install my project because of this dependency :

npm ERR! Error while executing:
npm ERR! /usr/local/bin/git ls-remote -h -t ssh://[email protected]/DABH/diagnostics.git
npm ERR! 
npm ERR! ssh: connect to host github.com port 22: Connection timed out
npm ERR! fatal: Could not read from remote repository.
npm ERR! 
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.
npm ERR! 
npm ERR! exited with error code: 128

Wonder if the issue is it's trying to reach the dep over ssh instead of https.

Can one of you try modifying winston's package.json so that the diagnostics dep is
git+https://github.com/DABH/diagnostics.git
? That should force it to use https but I want to be 100% sure that solves your issue before doing another hotifx release. Thanks!

I'm having the same issue when installing through docker.
I tried to modify the package.json, but I am not sure if I am doing it right.
in node_modules/winston/package.json I changed: "diagnostics": "github:DABH/diagnostics#master",
into: "diagnostics": "git+https://github.com/DABH/diagnostics.git",

This is not working, but I would have expected to need to change a dependency ending with "diagnostics.git" but I could not find that in the project.

edit: I am using 'node:12.10.0-alpine' as a base image for docker

I've been investigating about the issue and looks like the problem comes from alpine-based docker image. Even the following Dockerfile fails to build, regardless of node version.

FROM node:14-alpine

RUN npm install git+https://github.com/lodash/lodash

Ah, because the dep is coming from github, you need git...

FROM node:14-alpine

RUN apk update && apk upgrade && \
    apk add --no-cache bash git openssh

RUN npm install git+https://github.com/lodash/lodash

I understand that's not a great solution. The alternative is I have to publish my diagnostics fork on NPM, but that package is already on NPM so I guess I'd need to change the name of my repo or something so I can publish uniquely. Any tips welcome else I'll look at this later today.

Yes I've come up with the same solution.(I couldn't even imagine that git isn't shipped on alpine..) I'm fine with that solution.

The problem was not with winston so I'm closing this. Thanks for the help!

Thanks, see my post above ^^

@DABH @Kivol

hum, yep, I understand, Thx :)

For me the solution remains temporary and the issue should not be closed.

An NPM package should not require git for installation but only npm. If you use a FORK from another package because this one does not correspond to your need. I think this FORK must be integrated at the source or become a project maintained for Winston and therefore published as you suggested. It would be quite strange to impose the installation of git or any other tools for the installation of an npm package, for hundreds docker image. Images and process must be as lite as possible

Hi, I just want to express that git shouldn't be a dep for winstonjs. Hope this can be resolved. We have a few hundreds of docker images and I don't think modifying all of them would be very ideal. And I am sure a lot of us would feel the same. :)

If 3.3.x really does have such breaking change, we should move it to 4.x instead.

@DABH @Kivol

Second the comments above about this change being a breaking change. We have alpine docker images in production that will break due to this.

If this is required, then would support a 4.x change.

Wow, this one breaks the internet... :)
Very strange to require git indeed.

I have the same problem not in a docker image but in my enterprise network.

I use artifactory for download all dependencies (npm and github was blocked). If you use your fork, all projects without public access will fail. The biggest impact is for companies or CI/CD with restreint access.

For my point of view if you want keep your fork, you need to be standard and create a new package npm and not referer to a github repo.

So why is this ticket still closed?

Same problem here, please fix it. Unfortunately winston is installed as a module of a subdependency, so we can not directly modify the version. This breaks our CI pipeline that has no access to public github.

+1 for this issue, this breaks our CI pipeline.
Please revert the changes.

@Kivol please re-open, install git is not an option for many-many projects
especially when winston is not direct dependency.

+1 as well. This violates build once principle and breaks builds for our consumers. Maybe reverting until fixed is a good option here?

Just to say that I think the comments above shows clearly how much Winston is used and depending on by many projects. So whilst it's a pain when issues occur - I hope I speak for many - when I say we do value the contribution Winston and it's developers make.

Same here.
Two points to add:

  1. adding dependencies to the CI/CD job based on an Alpine image breaks the concept and has a cost (think "_green dev_")
  2. in a corporate environment, we can not change the overall network (if ever we could!) configuration to get just one package

Thanks for the active comments, please have patience for a couple hours as we try to roll out a better (non-git-dependent) solution for this.

All, v3.3.2 has been released, this downloads the forked diagnostics dependency from NPM not GitHub so it should work for you. Please feel free to confirm or deny. Thanks!

Thanks for the fix.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

exortech picture exortech  ·  3Comments

kjin picture kjin  ·  3Comments

sinai-doron picture sinai-doron  ·  3Comments

KingRial picture KingRial  ·  3Comments

JaehyunLee-B2LiNK picture JaehyunLee-B2LiNK  ·  3Comments