NestJS 和 docker-compose 构建时出错，找不到主文件

Question

所以我一直在使用使用 docker compose 和 Typescript 的 NestJS 应用程序。 直到最近我才遇到任何问题，现在每次我执行docker-compose build myApp和docker-compose up myApp时，容器都会失败并显示以下错误消息：

我已经尝试了一些方法来解决这个问题，例如我删除了容器和图像，然后使用docker-compose build --no-cache myApp再次重建它，但这没有用。 我不知道为什么有时它会起作用，但大多数时候它不起作用。 在我看来，这是一个随机的结果，我不知道在删除容器和图像后是否应该等待更长时间才能使其正常工作。 我认为问题在于 Nest 构建没有正确完成。 我需要找到一种方法来解决这个问题，因为我真的花了很多时间试图找到解决方案。

这是我的 dockerfile 和我的 package.json。

Dockerfile

FROM node:14.17.0-alpine

WORKDIR /tmp

COPY . .

RUN npm install

RUN npm run build

EXPOSE 3005

ENV NODE_TLS_REJECT_UNAUTHORIZED=0

# Run it
ENTRYPOINT ["node", "/tmp/dist/main"]

package.json

{
  "name": "carbon-api",
  "private": true,
  "version": "0.2.1",
  "description": "",
  "license": "UNLICENSED",
  "scripts": {
    "prebuild": "rimraf dist",
    "build": "nest build",
    "format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
    "start": "nest start",
    "start:dev": "nest start --watch",
    "start:debug": "nest start --debug --watch",
    "start:prod": "node dist/main",
    "lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage --no-cache",
    "test:export": "jest --coverage && jest-coverage-to-csv ./coverage/api-sumary.json ./coverage/api-sumary.csv",
    "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
    "test:e2e": "jest --config ./test/jest-e2e.json"
  },
  "dependencies": {
    "@casl/ability": "^5.2.2",
    "@grpc/proto-loader": "^0.5.6",
    "@nestjs/common": "^7.5.1",
    "@nestjs/core": "^7.5.1",
    "@nestjs/jwt": "^7.2.0",
    "@nestjs/microservices": "^7.2.0",
    "@nestjs/passport": "^7.1.5",
    "@nestjs/platform-express": "^7.5.1",
    "@nestjs/swagger": "^4.5.10",
    "@nestjs/typeorm": "^7.1.0",
    "@types/bcrypt": "^3.0.0",
    "aws-sdk": "^2.955.0",
    "bcryptjs": "^2.4.3",
    "body-parser": "^1.19.0",
    "body-parser-xml": "^2.0.0",
    "class-transformer": "^0.4.0",
    "class-validator": "^0.13.1",
    "dotenv": "^8.2.0",
    "grpc": "^1.24.4",
    "mysql": "^2.18.1",
    "nest-access-control": "^2.0.2",
    "nest-winston": "^1.3.5",
    "passport": "^0.4.1",
    "passport-jwt": "^4.0.0",
    "passport-local": "^1.0.0",
    "redis": "^3.0.2",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^3.0.2",
    "rxjs": "^6.6.3",
    "swagger-ui-express": "^4.1.4",
    "typeorm": "^0.2.31",
    "winston": "^3.3.3"
  },
  "devDependencies": {
    "@nestjs/cli": "^7.5.1",
    "@nestjs/schematics": "^7.1.3",
    "@nestjs/testing": "^7.5.1",
    "@types/express": "^4.17.8",
    "@types/jest": "^26.0.15",
    "@types/multer": "^1.4.7",
    "@types/node": "^14.14.6",
    "@types/passport-jwt": "^3.0.4",
    "@types/passport-local": "^1.0.33",
    "@types/supertest": "^2.0.10",
    "@typescript-eslint/eslint-plugin": "^4.6.1",
    "@typescript-eslint/parser": "^4.6.1",
    "eslint": "^7.12.1",
    "eslint-config-prettier": "^6.15.0",
    "eslint-plugin-prettier": "^3.1.4",
    "jest": "^26.6.3",
    "prettier": "^2.1.2",
    "supertest": "^6.0.0",
    "ts-jest": "^26.4.3",
    "ts-loader": "^8.0.8",
    "ts-node": "^9.0.0",
    "tsconfig-paths": "^3.9.0",
    "typescript": "^4.0.5",
    "jest-coverage-to-csv": "^1.1.0"
  },
  "jest": {
    "moduleFileExtensions": [
      "js",
      "json",
      "ts"
    ],
    "coveragePathIgnorePatterns": [
      ".module.ts",
      ".config.ts",
      "main.ts",
      ".entity.ts",
      ".dto.ts",
      ".enum.ts",
      "constants.ts",
      "paginationParams.ts"
    ],
    "rootDir": "src",
    "testRegex": ".*\\.spec\\.ts$",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage",
    "coverageReporters": [
      [
        "json-summary",
        {
          "file": "api-sumary.json"
        }
      ],
      "html"
    ],
    "testEnvironment": "node"
  }
}

Answer 1

因此，对于那里的任何人，也许它很有用。

问题是我决定运行npm install以便能够在我的本地机器上运行单元测试。 这对我的package-lock.json文件进行了一些更改，这在 docker 的构建过程中导致了此问题（如果我没有添加新的依赖项，我不知道为什么要对其进行更改）。

我注意到它是因为 git 显示此文件已修改，而它应该与上次保持相同。

无论哪种方式，我的解决方案是 go 到我项目的先前工作版本，复制旧的 package-lock.json 和瞧，解决了这个问题。