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.

Sign up for GitHub

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

Jump to bottom

Webpack build fails on node:16-alpine docker base image #9504

Closed
4 of 15 tasks
ThatNerdUKnow opened this issue Apr 28, 2022 · 10 comments
Closed
4 of 15 tasks

Webpack build fails on node:16-alpine docker base image #9504

ThatNerdUKnow opened this issue Apr 28, 2022 · 10 comments
Labels
needs triage This issue has not been looked into

Comments

@ThatNerdUKnow
Copy link

ThatNerdUKnow commented Apr 28, 2022 •
edited
Loading

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

I'm trying to take advantage of multi-stage builds in docker and I wanted to use webpack to bundle my code and dependencies together in ./dist but I get the following error when building my dockerfile

nest build --webpack
#11 1.568
#11 38.53 /node_modules/@nestjs/cli/node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:84
#11 38.53                                                                       if (err) return callback(err);
#11 38.53                                                                       ^
#11 38.53
#11 38.53 RangeError: Maximum call stack size exceeded
#11 38.53     at /node_modules/@nestjs/cli/node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:84:10
#11 38.53     at /node_modules/@nestjs/cli/node_modules/enhanced-resolve/lib/Resolver.js:434:24
#11 38.53     at eval (eval at create (/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:27:1)
#11 38.53     at /node_modules/tsconfig-paths-webpack-plugin/lib/plugin.js:103:17
#11 38.53     at /node_modules/@nestjs/cli/node_modules/enhanced-resolve/lib/Resolver.js:434:24
#11 38.53     at eval (eval at create (/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:12:1)
#11 38.53     at /node_modules/@nestjs/cli/node_modules/enhanced-resolve/lib/Resolver.js:434:24
#11 38.53     at eval (eval at create (/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:27:1)
#11 38.53     at /node_modules/@nestjs/cli/node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:88:10
#11 38.53     at /node_modules/@nestjs/cli/node_modules/enhanced-resolve/lib/Resolver.js:434:24

When I use nest build --webpack from the windows command line it builds perfectly fine but it fails in the node:16-alpine docker image

Minimum reproduction code

https://gist.github.com/ThatNerdUKnow/926655d5462142e2b7b3096974581c60

Steps to reproduce

Dockerfile:

FROM node:16-alpine

COPY package*.json ./

RUN npm ci

COPY . .

RUN npm run build

CMD [ "npm", "run", "start:prod" ]

NPM Script

build: 'nest build --webpack'

Expected behavior

I expect nest build --webpack to behave the same on docker as it does on my local system. On my system nest builds main.js under ./dist but in docker I get the aforementioned error

Package

  • I don't know. Or some 3rd-party package
  • @nestjs/common
  • @nestjs/core
  • @nestjs/microservices
  • @nestjs/platform-express
  • @nestjs/platform-fastify
  • @nestjs/platform-socket.io
  • @nestjs/platform-ws
  • @nestjs/testing
  • @nestjs/websockets
  • Other (see below)

Other package

@nestjs/cli

NestJS version

8.0.9

Packages versions

"dependencies": {
    "@nestjs/common": "^8.0.9",
    "@nestjs/config": "^1.0.2",
    "@nestjs/core": "^8.0.9",
    "@nestjs/platform-express": "^8.0.9",
    "@nestjs/swagger": "^5.1.0",
    "axios": "^0.21.4",
    "class-transformer": "^0.4.0",
    "class-validator": "^0.13.1",
    "nest-winston": "^1.6.0",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^3.0.2",
    "rxjs": "^7.1.0",
    "swagger-ui-express": "^4.1.6",
    "uuid": "^8.3.2",
    "winston": "^3.6.0"
  },
  "devDependencies": {
    "@nestjs/cli": "^8.2.4",
    "@nestjs/schematics": "^7.3.0",
    "@nestjs/testing": "^7.6.15",
    "@types/express": "^4.17.11",
    "@types/jest": "^26.0.22",
    "@types/node": "^14.14.36",
    "@types/supertest": "^2.0.10",
    "@typescript-eslint/eslint-plugin": "^4.19.0",
    "@typescript-eslint/parser": "^4.19.0",
    "eslint": "^7.22.0",
    "eslint-config-prettier": "^8.1.0",
    "eslint-plugin-prettier": "^3.3.1",
    "jest": "^26.6.3",
    "prettier": "^2.2.1",
    "supertest": "^6.1.3",
    "ts-jest": "^26.5.4",
    "ts-loader": "^8.0.18",
    "ts-node": "^9.1.1",
    "tsconfig-paths": "^3.9.0",
    "typescript": "^4.2.3"
  },

Node.js version

16-alpine

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response
@ThatNerdUKnow ThatNerdUKnow added the needs triage This issue has not been looked into label Apr 28, 2022
@micalevisk
Copy link
Member

please share the whole project and the steps to reproduce your issue.

@ThatNerdUKnow
Copy link
Author

ThatNerdUKnow commented May 1, 2022 •
edited
Loading

I've checked this morning and npx nest build --webpack will fail on any project boostrapped with nest new and built using the following Dockerfile using docker build .

FROM node:16-alpine

COPY package*.json

RUN npm ci

COPY . .

RUN npx nest build --webpack

CMD ["npm","run","start:prod"]

@ThatNerdUKnow
Copy link
Author

Added a branch to an example project
https://github.com/ThatNerdUKnow/nest-course/tree/dockerbuild

@jmcdo29
Copy link
Member

jmcdo29 commented May 1, 2022

I can confirm this does happen, it seems like it's related to enhanced-resolve from webpack and possibly the tsconfig-paths-webpack-plug. I haven't been able to pinpoint the issue yet. One option would be to run the docker container with more memory and set a large stack and max-old-space-size and see if that helps. We might also try downgrading webpack to v4, but I know that entails a lot of changes to the default config to make sure everything works.

@ThatNerdUKnow
Copy link
Author

Correct me if I'm wrong but docker has access to all system ram, right? Also, how do I set this max old space size variable?

@jmcdo29
Copy link
Member

jmcdo29 commented May 1, 2022

You're right, I was reading through errors too quickly. This is a recursive error in webpack for some reason, increasing the max-old-space-size most likely won't fix the issue either. I wonder what plugin with webpack is causing this issue.

@revinsys
Copy link

As I understand it, the enhanced-resolve module goes into recursive descent, looked at the logs, it tries to find the file ////////src/main.ts
If you explicitly specify WORKDIR, then the assembly and launch work
Here is an example Dockerfile that started for me

FROM node:16-alpine

WORKDIR /app

COPY ./package*.json ./

RUN npm ci

COPY . .

RUN npx nest build --webpack

CMD ["npm","run","start:prod"]

@ThatNerdUKnow
Copy link
Author

Thanks! I'll give it a try

@ThatNerdUKnow
Copy link
Author

Setting the workdir worked for me, Is there a reason for this behavior?

@jmcdo29
Copy link
Member

jmcdo29 commented May 16, 2022

I can only assume what enhanced-resolve is doing, probably trying to go ../ from process.cwd(), but process.cwd() is set to / when WORKDIR is not set, so ../ is the same as / which means that enhanced-resolve cannot move up a directory, and it gets into a loop of trying to move up and being unable to.

As we have a solution, and this is not related directly to Nest, I'm going to close this out

@jmcdo29 jmcdo29 closed this as completed May 16, 2022
@revinsys revinsys mentioned this issue May 16, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs triage This issue has not been looked into
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@revinsys @micalevisk @jmcdo29 @ThatNerdUKnow