Nest CLI generates the wrong package.json file

[rdev32]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

When you're about to launch nest just after using nest new project-name
this shows up
error TS2688: Cannot find type definition file for 'mime'.

after trying the stackblitz build. I noticed the CLI tool generates the wrong dependencies this should be fixed asap

Minimum reproduction code

https://stackblitz.com/edit/nestjs-typescript-starter-xjcum3?file=package.json

Steps to reproduce

1. npm i -g @nestjs/cli
2. nest new project-name
3. select yarn as package manager
4. run yarn start

Expected behavior

it should launch the server

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

No response

NestJS version

10.0.0

Packages versions

{
  "name": "untitled",
  "version": "0.0.1",
  "description": "",
  "author": "",
  "private": true,
  "license": "UNLICENSED",
  "scripts": {
    "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",
    "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": {
    "@nestjs/common": "^10.0.0",
    "@nestjs/core": "^10.0.0",
    "@nestjs/platform-express": "^10.0.0",
    "reflect-metadata": "^0.2.0",
    "rxjs": "^7.8.1"
  },
  "devDependencies": {
    "@nestjs/cli": "^10.0.0",
    "@nestjs/schematics": "^10.0.0",
    "@nestjs/testing": "^10.0.0",
    "@types/express": "^4.17.17",
    "@types/jest": "^29.5.2",
    "@types/node": "^20.3.1",
    "@types/supertest": "^6.0.0",
    "@typescript-eslint/eslint-plugin": "^6.0.0",
    "@typescript-eslint/parser": "^6.0.0",
    "eslint": "^8.42.0",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-prettier": "^5.0.0",
    "jest": "^29.5.0",
    "prettier": "^3.0.0",
    "source-map-support": "^0.5.21",
    "supertest": "^6.3.3",
    "ts-jest": "^29.1.0",
    "ts-loader": "^9.4.3",
    "ts-node": "^10.9.1",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.1.3"
  },
  "jest": {
    "moduleFileExtensions": [
      "js",
      "json",
      "ts"
    ],
    "rootDir": "src",
    "testRegex": ".*\\.spec\\.ts$",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage",
    "testEnvironment": "node"
  }
}

Node.js version

20

In which operating systems have you tested?

• Linux
• macOS
• Windows

Other

os: fedora 39
ide: vscode stable
package manager: yarn

[micalevisk]

indeed

I guess there's something wrong with the dependencies of @nestjs/cli@10.3.2

v10.3.1 went fine, so you can use it for now

npx @nestjs/cli@10.3.1 new project-name
cd project-name
# to upgrade packages
ncu -u

[micalevisk]

actually, the error exists on @nestjs/cli@10.3.1 as well due to Yarn(?)

Using NPM went fine

And seems to be related with a broken version of @types/mime (v4.0.0):

comparing with v3.x:

---

Same as firebase/firebase-admin-node#2512

[rdev32]

actually, the error exists on @nestjs/cli@10.3.1 as well due to Yarn(?)

Using NPM went fine

And seems to be related with a broken version of @types/mime (v4.0.0):

comparing with v3.x:

Same as firebase/firebase-admin-node#2512

Using npm instead of yarn worked for me. is a workaround but the bug is still there :(
Considering nest supports yarn and pnpm this is a bummer

[WayneStilwell]

As described in the linked issue, you can temporarily add this to your package.json if you're using yarn:

  "resolutions": {
    "@types/mime": "^3.0.4"
  }

@types/express depends on @types/serve-static, which is pulling the latest version of @types/mime (v4). Mime v4 includes its types, so the @types/mime package is no longer needed. And is deprecated in v4 (as of yesterday).

This PR for @types/serve-static appears to set the appropriate version of @types/mime. Once that's merged and released, you should be able to remove the code above.

[cosigyn]

I am in a nest.js monorepo, I just wanted to add that I am experiencing this in non-nest related packages too,

{
  "name": "api-types",
  "main": "src/index.ts",
  "scripts": {
    "compile": "swc src --out-dir dist"
  },
  "dependencies": {
    "@prisma/client": "5.10.2",
    "@ts-rest/core": "^3.36.0",
    "zod": "3.21.1",
    "tsconfig": "workspace:*"
  },
  "devDependencies": {
    "typescript": "^5.4.3"
  }
}

[julienfdev]

This is indeed what happened, absolutely not related to Nest indeed :
https://www.npmjs.com/package/@types/mime?activeTab=versions

Still baffling to me that this can happen and trash half the CI/CDs on the internet...
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/serve-static/package.json

Thanks @WayneStilwell for the workaround, this is infuriating.

[rdev32]

I don't want to bother but for educational purposes. Can I ask why the package.json build from the stackblitz site is different from what nest/cli generates? Also why does it work on npm but not on yarn or pnpm? It is clear to me that locking @types/mime solves the issue but out of curiosity does this mean npm takes frozen modules?

[micalevisk]

that was fixed by now.

npx @nestjs/cli@latest new project-name
# select yarn
cd project-name
yarn start # working as expected