This is confusing so I apologize if I don't word this sufficiently well.
Essentially, I'm leveraging npm's --force flag to bypass a conflicting peer-dependency error with npm#8. Subsequent npm install s of the dependencies complete without any errors. When attempting to install dependencies via docker, however, the original error returns.
So, originally:
encounter error:
npm ERR! ERESOLVE could not resolve
...
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
bypass via npm install --force
subsequent npm installs work without issue in new local environments (e.g. clone into new dir, run npm install)
However, attempting to npm install or npm ci (npm ci ensures a lockfile already exists) in a docker build continues throws the original error:
npm ERR! ERESOLVE could not resolve
...
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
Which, to me, suggests the lockfile isn't being respected. But we know it exists because otherwise npm ci would error.
Does anyone have an idea as to why this might be the case?
Dockerfile I'm testing with:
# // Dockerfile
# ==== CONFIGURE =====
# Use a Node 16 base image
FROM node:16-alpine
# Set the working directory to /app inside the container
WORKDIR /app
# Copy app files
COPY package-lock.json .
RUN echo $(ls)
# ==== BUILD =====
# Install dependencies (npm ci makes sure the exact versions in the lockfile gets installed)
RUN npm ci
# Build the app
RUN npm run build
# ==== RUN =======
# Set the env to "production"
ENV NODE_ENV production
# Expose the port on which the app will be running (3000 is the default that `serve` uses)
EXPOSE 3000
# Start the app
CMD [ "npx", "serve", "build" ]
Local npm is v8.1, docker npm is v8.19. Seems they introduced a breaking change at some point between those two versions.
From official docs:
NOTE: If you create your package-lock.json file by running npm install with flags that can affect the shape of your dependency tree, such as --legacy-peer-deps or --install-links, you must provide the same flags to npm ci or you are likely to encounter errors. An easy way to do this is to run, for example, npm config set legacy-peer-deps=true --location=project and commit the .npmrc file to your repo.
Related
Here are my files.
Here is I think the core of the problem.
Could not resolve dependency:
npm ERR! peer graphql#"^0.12.0 || ^0.13.0 || ^14.0.0" from graphql-middleware#4.0.2
docker-compose.yml
version: '3.7'
services:
apollo:
container_name: apollo
build:
context: .
dockerfile: Dockerfile
environment:
- NODE_ENV=development
volumes:
- '.:/app'
- '/app/node_modules'
ports:
- 4000:4000
restart: always
Dockerfile
# Use the official image as a parent image.
FROM node:current-slim
# Set the working directory.
WORKDIR /app
# Setting environment path.
ENV PATH=/app/node_modules/.bin:$PATH
# Copy the file from your host to your current location.
COPY package.json .
# Run the command inside your image filesystem.
RUN npm init --yes
RUN npm install --save cors apollo-server-express express graphql reflect-metadata type-graphql apollo-datasource-rest soap jsonwebtoken --yes
RUN npm install nodemon -g --yes
# Add metadata to the image to describe which port the container is listening on at runtime.
EXPOSE 4000
# Copy the rest of your app's source code from your host to your image filesystem.
COPY . .
CMD [ "nodemon", "index.js" ]
Dependency Error
$ docker-compose up --build
Building apollo
Step 1/10 : FROM node:current-slim
---> f3f62dfcc735
Step 2/10 : WORKDIR /app
---> Using cache
---> 33088e65c748
Step 3/10 : ENV PATH=/app/node_modules/.bin:$PATH
---> Using cache
---> c7f742267b26
Step 4/10 : COPY package.json .
---> Using cache
---> 76285ea4a8ca
Step 5/10 : RUN npm init --yes
---> Using cache
---> 29a3d715136b
Step 6/10 : RUN npm install --save cors apollo-server-express express graphql reflect-metadata type-graphql apollo-datasource-rest soap jsonwebtoken --yes
---> Running in 1e4472bcd901
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: apollo-express-server#1.0.0
npm ERR! Found: graphql#15.4.0
npm ERR! node_modules/graphql
npm ERR! graphql#"^15.3.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer graphql#"^0.12.0 || ^0.13.0 || ^14.0.0" from graphql-middleware#4.0.2
npm ERR! node_modules/graphql-middleware
npm ERR! graphql-middleware#"^4.0.2" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /root/.npm/eresolve-report.txt for a full report.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-11-05T16_19_42_605Z-debug.log
ERROR: Service 'apollo' failed to build : The command '/bin/sh -c npm install --save cors apollo-server-express express graphql reflect-metadata type-graphql apollo-datasource-rest soap jsonwebtoken --yes' returned a non-zero code: 1
There is not need to downgrade to npm 6.
Indeed npm 7 can still be used with option --legacy-peer-deps.
npm install --legacy-peer-deps
The problem here is certainly with NPM and the packages you are trying to install rather than anything to do with Docker.
Unfortunately, I am not able to reproduce the exact error that you are facing. That could be because:
something changed in the time between now and whenever this problem occurred;
there are some essential details that you are not showing us.
Either way, there's a general way in which such issues are solved, which should help. But first an explanation.
Dependencies, peer dependencies and conflicts
NPM's package (dependency) management mechanism allows packages (dependencies) to have:
(direct) dependencies - installed automatically with the package;
peer dependencies - have to be manually installed by the consumer of the package.
However, NPM does not allow multiple versions of the same package to coexist.
Also, as you may know, packages use standard semantic versioning, which means that a major version change indicates a breaking change.
Due to these two reasons, clashes occur if one package requires dependency A to be v1, while another wants the same dependency A to be v2.
NPM v7
NPM v7 was recently released and this is the version that current (as of November 2020) node:current images use.
Probably the biggest changes brought about by NPM7 relate to peer dependencies - NPM should now be able to install them automatically, if possible. Read more here.
As described in the document, in cases where it's not possible to solve the conflicts, NPM should now throw errors rather than warnings, which is what you are seeing.
I, on the other hand, only managed to get warnings and no errors using your setup and NPM v7.0.8, and I don't know why. The problems reported were essentially the same, however, so the resolution ought to be very similar.
How to solve conflicts
The only solution that I'm aware of is manual conflict resolution - the developer needs to adjust their dependencies to play along.
In your specific case the problem seems to be with the graphql package. The latest graphql package is v15, which is also a peer dependency of the latest type-graphql package (v1).
However, apollo-server-express has a few dependencies, which apparently only support graphql up to and including v14.
While you wait for apollo-server-express to fully support v15, you may opt for graphql v14 altogether by downgrading the only package that requires v15. So if you change your npm install to this:
npm install --save cors apollo-server-express express graphql#14 reflect-metadata type-graphql#0 apollo-datasource-rest soap jsonwebtoken
it ought to work... Notice that we are explicitly installing graphql#14 and type-graphql#0 (yes, version zero).
Alternative solution
Going to give you some bad advice too. In some cases a missing peer dependency may not be a problem, particularly if you never use the related functionality. In your case, it may be even less of a problem because you do have the dependency, just not the required version. It's entirely possible that a wrong version would do just fine. If you feel lucky (or if you're sure of you're doing) and you really wish to proceed with graphql v15, you could either:
suppress any NPM output to silence the errors;
downgrade to NPM v6, which works quite differently (although it will still warn you of peer dependency problems).
Proceed with caution!
I have a similar error, in my case just need to manually install all dependencies
npm install --save express
npm install --save express-graphql
npm install --save graphql
npm install --save mongoose
npm install package_name --legacy-peer-deps
Or
npm install package_name --force
Will fix the issue.
I had the same issue while trying to build a reactJS application in which i had used CoreUI and other JS libraries. Some of this dependacies i noted they use legacy dependacies in them and seemed like in their package.json file they have explicitly specified a version to be used. After trying all this solutions above, docker (docker build .) still could not build my image.
i changed my base image from node:16-alpine3.11 to node:12-alpine3.11 and everything worked perfectly.
Using this base image i was able to avoid using
npm install --save --legacy-peer-deps which failed to work on my case
My recommendations to anyone who might experience this issues is to just try various node docker images.
I am trying to create a docker image that I can pack an aspnetcore2.0/angular-universal application and due to my insufficient docker experience I been keep running into issues. I could really use some help.
Here is the dockerfile content:
FROM microsoft/aspnetcore-build:2.0 AS build-env
WORKDIR /app
COPY *.csproj ./
RUN npm cache clean --force
RUN npm install npm#latest
RUN npm install #angular/cli#latest
RUN npm install #ngtools/webpack#next
RUN node -v
RUN dotnet restore
COPY . ./
RUN dotnet publish -c Release -o out
FROM microsoft/microsoft/aspnetcore:2.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT [ "dotnet", "net-streetStyleCrew.dll" ]
since the aspnetcore-build:2.0 comes with a too old npm/node it has to be updated. And it have not go to angular-cli part, but i assume that need to be fresh as well of course.
And here is the trouble that I am running into now, and i have no clue how to resolve what appears to be a network issue inside the container when attempts to update:
Step 5/15 : RUN npm install npm#latest
---> Running in 72531196fc83
npm ERR! Windows_NT 10.0.16299
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "npm#latest"
npm ERR! node v6.13.0
npm ERR! npm v3.10.10
npm ERR! code ENOTFOUND
npm ERR! errno ENOTFOUND
npm ERR! syscall getaddrinfo
npm ERR! network getaddrinfo ENOTFOUND registry.npmjs.org registry.npmjs.org:443
npm ERR! network This is most likely not a problem with npm itself
npm ERR! network and is related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly. See: 'npm help config'
npm ERR! Please include the following file with any support request:
npm ERR! C:\app\npm-debug.log
The command 'cmd /S /C npm install npm#latest' returned a non-zero code: 1
I am trying to run this on a windows container, because I don't have a whole lot of experience with Linux either.
I am absolutely open to any suggestion as well that could improve my approach to the basic concept. Thanks in advance.
Firstly, I think the specific issue is not a Docker related issue. This is a network related issue. Maybe this SO thread will help.
Regarding your Dockerfile:
The official best practice recommends reducing the number of layers. Each RUN command creates a layer. At the same time, you may want to have multiple RUN command to improve readability and take the benefit of caching. So, you need to find a balance between the two. In this particular case, I think you should chain the npm commands in a single RUN statement.
Also, I think instead of using the latest version, you should specify the exact version. The latest will always download the latest at the time of image creation and you don't know whether this new version is having a bug that breaks your app. So, the idea is to test in a specific version and use that same version in production. If you want to upgrade later to more recent version, you need to first test your app with the new version and then update your Dockerfile with the new version
Here is an e.g.
RUN mkdir /home/aus/.npm; \
npm config set prefix /home/aus/.npm; \
npm install --quiet --no-progress -g webpack#3.11.0; \
npm install --quiet --no-progress -g #angular/cli#1.7.2; \
npm install --quiet --no-progress;
I'm trying to build a docker image with a global install of firebase-tools and angular-cli.
I'm building the same image for two versions of node: 6.x (LTS boron) and v8.x (latest alpine). Locally, both images build fine, but when I try to build in docker hub only the v6.x builds successfully. With the v8.x it gets trapped in the access permissions for undefined and nobody user. I'm already using the root user (USER root), since without this setting (or using USER node) both images fail to build.
This is my Dockerfile:
FROM node:latest
USER root
RUN npm install --quiet --no-progress -g #angular/cli#latest firebase-tools
RUN npm cache clean --force
And this is the output:
Step 4/5 : RUN npm install --quiet --no-progress -g #angular/cli#latest firebase-tools
---> Running in fce3da11b04e
npm WARN deprecated node-uuid#1.4.8: Use uuid module instead
/usr/local/bin/firebase -> /usr/local/lib/node_modules/firebase-tools/bin/firebase
/usr/local/bin/ng -> /usr/local/lib/node_modules/#angular/cli/bin/ng
> node-sass#4.5.3 install /usr/local/lib/node_modules/#angular/cli/node_modules/node-sass
> node scripts/install.js
Unable to save binary /usr/local/lib/node_modules/#angular/cli/node_modules/node-sass/vendor/linux-x64-57 : { Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/#angular/cli/node_modules/node-sass/vendor'
at Object.fs.mkdirSync (fs.js:890:18)
at sync (/usr/local/lib/node_modules/#angular/cli/node_modules/mkdirp/index.js:71:13)
at Function.sync (/usr/local/lib/node_modules/#angular/cli/node_modules/mkdirp/index.js:77:24)
at checkAndDownloadBinary (/usr/local/lib/node_modules/#angular/cli/node_modules/node-sass/scripts/install.js:111:11)
at Object.<anonymous> (/usr/local/lib/node_modules/#angular/cli/node_modules/node-sass/scripts/install.js:154:1)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
errno: -13,
code: 'EACCES',
syscall: 'mkdir',
path: '/usr/local/lib/node_modules/#angular/cli/node_modules/node-sass/vendor' }
> grpc#1.3.8 install /usr/local/lib/node_modules/firebase-tools/node_modules/grpc > node-pre-gyp install --fallback-to-build --library=static_library
node-pre-gyp ERR! Tried to download(undefined): https://storage.googleapis.com/grpc-precompiled-binaries/node/grpc/v1.3.8/node-v57-linux-x64.tar.gz node-pre-gyp ERR! Pre-built binaries not found for grpc#1.3.8 and node#8.1.2 (node-v57 ABI) (falling back to source compile with node-gyp)
gyp WARN EACCES user "undefined" does not have permission to access the dev dir "/root/.node-gyp/8.1.2" gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp"
gyp WARN EACCES user "nobody" does not have permission to access the dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp/8.1.2" gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp"
gyp WARN EACCES user "nobody" does not have permission to access the dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp/8.1.2" gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp"
gyp WARN EACCES user "nobody" does not have permission to access the dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp/8.1.2" gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp"
gyp WARN EACCES user "nobody" does not have permission to access the dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp/8.1.2" gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/firebase-tools/node_modules/grpc/.node-gyp"
(infinite loop)
The problem is because while NPM runs globally installed module scripts as the nobody user, which kinds of makes sense, recent versions of NPM started setting the file permissions for node modules to root. As a result module scripts are no longer allowed to create files and directories in their module.
See discussion in NPM issue #3849, for some references.
A simple workaround, which makes sense in a docker environment, is to set the NPM default global user back to root, like so:
npm -g config set user root
After which you shouldn't have any more EACCES errors.
Please DO NOT set the user to root or use --unsafe-perm.
Simply use the node user, provided with the current official (e.g. alpine) images.
Commented Dockerfile below:
FROM node:15.5-alpine
# 👉 Security: do not use the `root` user.
ENV USER=node
# You can not use `${USER}` here, but reference `/home/node`.
ENV PATH="/home/node/.npm-global/bin:${PATH}"
# 👉 The `--global` install dir
ENV NPM_CONFIG_PREFIX="/home/node/.npm-global"
# All subsequent commands are run as the `node` user.
USER "${USER}"
# Pre-create the target dir for global install.
RUN mkdir -p "${NPM_CONFIG_PREFIX}/lib"
WORKDIR /usr/src/app
COPY package.json package-lock.json ./
# 👉 Configure NPM, so pkg get installed with correct credentials.
# Avoids `chmod u+x $DIR` and other workarounds.
RUN npm --global config set user "${USER}" \
&& npm --global --quiet --no-progress install \
&& npm cache clean --force
Extended version of #gabriel-araujo answer.
You can replace setting the user via the CLI flags (npm --global config set user "${USER}") by configuring this in the .npmrc file. Place user=node in the project roots .npmrc file or just set it directly from the Dockerfile.
RUN echo "user=node" > "${NPM_CONFIG_PREFIX}/etc/.npmrc"
If you use docker-compose.yml, you can add it as environment: - … variable.
Hope that helps you running a more safe NodeJS container somewhere and pull up some awesome stuff.
Use the --unsafe-perm flag:
npm install --quiet --no-progress --unsafe-perm -g #angular/cli#latest firebase-tools
I think that's still better than setting the npm user permanently to root. You can use --unsafe-perm only with the packages which cause problem
I was able to get it working by changing the default npm-global directory.
This is my dockerfile now:
FROM node:latest
USER node
RUN mkdir /home/node/.npm-global
ENV PATH=/home/node/.npm-global/bin:$PATH
ENV NPM_CONFIG_PREFIX=/home/node/.npm-global
RUN npm install --quiet --no-progress -g #angular/cli#latest firebase-tools
RUN npm cache clean --force
instead of forcing NPM's hand to install the package inside the container I bypassed this issue by mapping/referncing a host folder for the missing module
this also prevents future headaches for when I replace the docker image with the latest version, I won't have to repeat the stages to reinstall the missing module inside the container:
the steps i took:
create an empty folder on the host environment (will be used as a target for the node js modules). call it node_modules
when launching running the docker container use the --volume and --env switches
-- volume to pass map the new host folder (from step 1) to a folder accessible inside docker
--env to define/set an environment variable NPM_CONFIG_PREFIX from inside the docker to the /node_modules folder we created in step 1
access the container using :
sudo docker exec -i -t sh
and go to the folder above the folder right above the local /node_modules folder (this not the folder we mapped to the environment variable, but rather the preexisting folder that came with the docker image)
then run the command:
> npm install -g <mdule-name>
example
> npm install -g request
this will install the module in the host folder we've created. this module will also be accessible from both docker and host.
I'm fairly new to docker and I'm kind of experimenting with Angular CLI app. I managed to run it locally through my docker container. It works great, but when I try running it from my server it fails.
Server is hosted on DigitalOcean:
512 MB Memory / 20 GB Disk / FRA1 - Ubuntu Docker 17.03.0-ce on 14.04
I used dockerhub to transfer my container to the server.
When logging the container it gives me this:
** NG Live Development Server is running on http://0.0.0.0:4200. **
63% building modules 469/527 modules 58 active ...s/#angular/compiler/src/assertions.jsKilled
npm info lifecycle angular-test#0.0.0~start: Failed to exec start script
npm ERR! Linux 4.4.0-64-generic
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v6.10.3
npm ERR! npm v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! angular-test#0.0.0 start: `ng serve --host 0.0.0.0`
npm ERR! Exit status 137
npm ERR!
npm ERR! Failed at the angular-test#0.0.0 start script 'ng serve --host 0.0.0.0'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the angular-test package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! ng serve --host 0.0.0.0
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs angular-test
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls angular-test
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /usr/src/app/npm-debug.log
Here is my Dockerfile:
# Create image based on the official Node 6 image from dockerhub
FROM node:6
# Create a directory where our app will be placed
RUN mkdir -p /usr/src/app
# Change directory so that our commands run inside this new directory
WORKDIR /usr/src/app
# Copy dependency definitions
COPY package.json /usr/src/app
# Install dependecies
RUN npm install
# Get all the code needed to run the app
COPY . /usr/src/app
# Expose the port the app runs in
EXPOSE 4200
# Serve the app
CMD ["npm", "start"]
How come it runs locally and fails on server? Am I missing some dependencies?
ng serve is an angular-cli command. I'm guessing you need to install it globally in your docker file if you want to start your server like that on digital ocean:
RUN npm i -g angular-cli
I think it would be more typical to simply run the app using the naked node server in production. So your CMD would look more like this:
CMD ["node", "app.js"]
I am setting up docker for my React/Redux app, and I was wondering how to set it up in such way, that in production, on container setup, webpack compiles my whole code with production configuration, and then it removes itself, or something like that. Because the only thing I will need for my project is production code, and a simple node server that will serve it.
I'm not sure if I explained it well, since docker and webpack are still new things for me.
EDIT:
Alternatively I can even serve everything with an apache server, but I want everything to compile and setup just when I run docker-compose.
If I understand correctly, you want to trash your node dev dependencies from your image after your npm run build during the docker build.
You can do it but there is a little trick you must be aware of.
Each line in your Dockerfile result in a new step in the image and is pushed with the image.
So, if you execute in your Dockerfile :
RUN npm install # Install dev and prod deps
RUN npm run build # Execute your webpack build
RUN npm prune --production # Trash all devDependencies from your node_modules folder
Your image size will contains :
The first npm install
The npm run build
The result of the npm prune
Your image will be bigger than just :
RUN npm install # Install dev and prod deps
RUN npm run build # Execute your webpack build
Wich contains :
The first npm install
The npm run build
To avoid this problem you must do in your dockerfile :
RUN npm install && npm run build && npm prune --production
That way you will get a minimalistic image. With :
The npm run build
The result of the npm prune
Your final Dockerfile will be some sort of :
FROM node:7.4.0
ADD . /src
RUN cd /src && npm install && npm run build && npm prune --production # You can even use npm prune without the --production flag
ENV NODE_ENV production