Closed rdev32 closed 5 months ago
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
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 https://github.com/firebase/firebase-admin-node/issues/2512
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:
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
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.
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"
}
}
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.
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?
that was fixed by now.
npx @nestjs/cli@latest new project-name
# select yarn
cd project-name
yarn start # working as expected
Is there an existing issue for this?
Current behavior
When you're about to launch nest just after using
nest new project-name
this shows uperror 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
npm i -g @nestjs/cli
nest new project-name
yarn start
Expected behavior
it should launch the server
Package
Other package
No response
NestJS version
10.0.0
Packages versions
Node.js version
20
In which operating systems have you tested?
Other
os: fedora 39 ide: vscode stable package manager: yarn