nest new를 사용하면 안 되는 이유

최근 nest new로 생성한 프로젝트에서 문제가 발생했습니다. eslint의 버전이 8에서 9로 올라가면서, eslintrc.js를 eslint.config.js로 변경해야 하는 breaking change가 있었는데, 이 변경이 nest new로 자동 생성되는 파일에는 적용되지 않았습니다.

반면, nest new 대신 typescript-starter를 사용해 새로 생성한 프로젝트에는 이러한 이슈가 없었습니다. 이 경험을 통해 nest new보다는 다음 명령어를 사용하는 것이 더 안정적이라고 할 수 있습니다:

git clone https://github.com/nestjs/typescript-starter

Nest의 공식 문서에서는 두 명령어가 동일한 결과를 낸다고 적혀 있지만, 엄밀히 말하면 이는 잘못된 정보입니다. 아래는 nest new와 git clone으로 생성한 프로젝트의 차이점을 비교한 내용입니다.

$ diff -ur nest-new-project ts-starter-project

...

   "dependencies": {
-    "@nestjs/common": "^10.0.0",
-    "@nestjs/core": "^10.0.0",
-    "@nestjs/platform-express": "^10.0.0",
-    "reflect-metadata": "^0.2.0",
+    "@nestjs/common": "^10.3.2",
+    "@nestjs/core": "^10.4.4",
+    "@nestjs/platform-express": "^10.4.4",
+    "reflect-metadata": "^0.2.1",
     "rxjs": "^7.8.1"
   },
   "devDependencies": {
-    "@nestjs/cli": "^10.0.0",
-    "@nestjs/schematics": "^10.0.0",
-    "@nestjs/testing": "^10.0.0",
-    "@types/express": "^5.0.0",
-    "@types/jest": "^29.5.2",
-    "@types/node": "^20.3.1",
-    "@types/supertest": "^6.0.0",
-    "@typescript-eslint/eslint-plugin": "^8.0.0",
-    "@typescript-eslint/parser": "^8.0.0",
-    "eslint": "^9.0.0",
-    "eslint-config-prettier": "^9.0.0",
-    "eslint-plugin-prettier": "^5.0.0",
-    "jest": "^29.5.0",
-    "prettier": "^3.0.0",
+    "@nestjs/cli": "^10.4.5",
+    "@nestjs/schematics": "^10.1.0",
+    "@nestjs/testing": "^10.3.2",
+    "@swc/cli": "^0.3.9",
+    "@swc/core": "^1.4.0",
+    "@types/express": "^4.17.21",
+    "@types/jest": "^29.5.12",
+    "@types/node": "^20.11.16",
+    "@types/supertest": "^6.0.2",
+    "@typescript-eslint/eslint-plugin": "^6.21.0",
+    "@typescript-eslint/parser": "^6.21.0",
+    "eslint": "^8.56.0",
+    "eslint-config-prettier": "^9.1.0",
+    "eslint-plugin-prettier": "^5.1.3",
+    "jest": "^29.7.0",
+    "prettier": "^3.2.5",
     "source-map-support": "^0.5.21",
-    "supertest": "^7.0.0",
-    "ts-jest": "^29.1.0",
-    "ts-loader": "^9.4.3",
-    "ts-node": "^10.9.1",
+    "supertest": "^6.3.4",
+    "ts-jest": "^29.1.2",
+    "ts-loader": "^9.5.1",
+    "ts-node": "^10.9.2",
     "tsconfig-paths": "^4.2.0",
-    "typescript": "^5.1.3"
+    "typescript": "^5.3.3"

...

그 외에도 tsconfig나 소스 자체에서 차이점이 많습니다. 직접 비교해보는 것을 추천합니다.

위에서 볼 수 있듯이, typescript-starter는 Nest 사용자 커뮤니티에서 편의성과 안정성을 위해 고려한 많은 흔적이 있지만, nest new로 생성된 프로젝트는 관심과 지원이 다소 부족한 것으로 보입니다.

nest new를 사용할 때 자동 생성에 사용되는 파일의 템플릿은 nestjs/schematics 레포에서 확인할 수 있으며, 로컬에서도 다음 명령어로 위치를 확인할 수 있습니다:

$ fd -H -I prettierrc
22.9.0/lib/node_modules/@nestjs/cli/node_modules/@nestjs/schematics/dist/lib/application/files/ts/.prettierrc

놀랍게도, eslint의 버전을 8에서 9로 올린 원인 제공자는 Renovate Bot입니다. 이는 자동으로 package.json의 의존성 버전을 업데이트해주는 봇입니다. 관련 커밋은 여기에서 확인할 수 있습니다.

봇이 eslint를 8에서 9로 올리면서, eslintrc 또한 eslint.config.js로 이주했더라면 좋았겠지만, 그렇게 되지 않아 eslint가 에러를 내면서 Nest와 Node에 처음 입문한 많은 개발자들에게 혼란을 주었을 것입니다. 저 또한 지인의 에디터에서 발생한 에러를 함께 해결하다가 이 사실을 알게 되었습니다.

NestJS가 좀 더 안정적이 되기를 바라며 이 글을 마칩니다.