Nodemon not installed, but defined in package.json and yarn install run

[simonv3]

I’m incredibly puzzled by what’s happening. There are several people mentioning this issue in the forum but it looks like those folks weren’t running yarn install.

At some point my app just started telling me that nodemon wasn’t installed, despite it being listed in the devDependencies and it being installed through yarn install.

This is all happening after I clear the cache and redeploy (or whenever I try to deploy).

Jul 21 08:54:17 AM  ==> Cloning from https://github.com/funmusicplace/mirlo...
Jul 21 08:54:18 AM  ==> Checking out commit ff01d84e3566447444315f2bbfa362a5ba32ac01 in branch main
Jul 21 08:54:22 AM  ==> Using Node version 16.19.0 via /opt/render/project/src/.nvmrc
Jul 21 08:54:22 AM  ==> Docs on specifying a Node version: https://render.com/docs/node-version
Jul 21 08:54:23 AM  ==> Running build command 'yarn install && yarn migrate:deploy'...
Jul 21 08:54:24 AM  yarn install v1.22.5
Jul 21 08:54:24 AM  [1/4] Resolving packages...
Jul 21 08:54:24 AM  [2/4] Fetching packages...
Jul 21 08:54:43 AM  info @msgpackr-extract/msgpackr-extract-darwin-arm64@2.2.0: The platform "linux" is incompatible with this module.
Jul 21 08:54:43 AM  info "@msgpackr-extract/msgpackr-extract-darwin-arm64@2.2.0" is an optional dependency and failed compatibility check. Excluding it from installation.
Jul 21 08:54:43 AM  info @msgpackr-extract/msgpackr-extract-darwin-arm64@2.2.0: The CPU architecture "x64" is incompatible with this module.
Jul 21 08:54:43 AM  info @msgpackr-extract/msgpackr-extract-darwin-x64@2.2.0: The platform "linux" is incompatible with this module.
Jul 21 08:54:43 AM  info "@msgpackr-extract/msgpackr-extract-darwin-x64@2.2.0" is an optional dependency and failed compatibility check. Excluding it from installation.
Jul 21 08:54:43 AM  info @msgpackr-extract/msgpackr-extract-linux-arm@2.2.0: The CPU architecture "x64" is incompatible with this module.
Jul 21 08:54:43 AM  info "@msgpackr-extract/msgpackr-extract-linux-arm@2.2.0" is an optional dependency and failed compatibility check. Excluding it from installation.
Jul 21 08:54:43 AM  info @msgpackr-extract/msgpackr-extract-linux-arm64@2.2.0: The CPU architecture "x64" is incompatible with this module.
Jul 21 08:54:43 AM  info "@msgpackr-extract/msgpackr-extract-linux-arm64@2.2.0" is an optional dependency and failed compatibility check. Excluding it from installation.
Jul 21 08:54:43 AM  info @msgpackr-extract/msgpackr-extract-win32-x64@2.2.0: The platform "linux" is incompatible with this module.
Jul 21 08:54:43 AM  info "@msgpackr-extract/msgpackr-extract-win32-x64@2.2.0" is an optional dependency and failed compatibility check. Excluding it from installation.
Jul 21 08:54:43 AM  info fsevents@2.3.2: The platform "linux" is incompatible with this module.
Jul 21 08:54:43 AM  info "fsevents@2.3.2" is an optional dependency and failed compatibility check. Excluding it from installation.
Jul 21 08:54:43 AM  [3/4] Linking dependencies...
Jul 21 08:54:47 AM  [4/4] Building fresh packages...
Jul 21 08:54:53 AM  Done in 29.46s.
Jul 21 08:54:54 AM  yarn run v1.22.5
Jul 21 08:54:54 AM  $ DEBUG=prisma:client npx prisma migrate deploy
Jul 21 08:54:56 AM  Prisma schema loaded from prisma/schema.prisma
Jul 21 08:54:56 AM  Datasource "db": PostgreSQL database "blackbrd_s4t8", schema "public" at "dpg-ciompomnqqlfege07so0-a"
Jul 21 08:54:57 AM  
Jul 21 08:54:57 AM  39 migrations found in prisma/migrations
Jul 21 08:54:57 AM  
Jul 21 08:54:57 AM  
Jul 21 08:54:57 AM  No pending migrations to apply.
Jul 21 08:54:57 AM  Done in 3.33s.
Jul 21 08:54:58 AM  ==> Uploading build...
Jul 21 08:55:09 AM  ==> Build uploaded in 9s
Jul 21 08:55:10 AM  ==> Build successful 🎉
Jul 21 08:55:10 AM  ==> Deploying...
Jul 21 08:55:41 AM  ==> Using Node version 16.19.0 via /opt/render/project/src/.nvmrc
Jul 21 08:55:41 AM  ==> Docs on specifying a Node version: https://render.com/docs/node-version
Jul 21 08:55:41 AM  ==> Starting service with 'yarn staging'
Jul 21 08:55:42 AM  yarn run v1.22.5
Jul 21 08:55:42 AM  $ NODE_ENV=production nodemon src/index.ts
Jul 21 08:55:42 AM  /bin/sh: 1: nodemon: not found
Jul 21 08:55:42 AM  error Command failed with exit code 127.
Jul 21 08:55:42 AM  info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Jul 21 08:55:45 AM  ==> Using Node version 16.19.0 via /opt/render/project/src/.nvmrc
Jul 21 08:55:45 AM  ==> Docs on specifying a Node version: https://render.com/docs/node-version
Jul 21 08:55:45 AM  ==> Starting service with 'yarn staging'
Jul 21 08:55:45 AM  yarn run v1.22.5
Jul 21 08:55:46 AM  $ NODE_ENV=production nodemon src/index.ts
Jul 21 08:55:46 AM  /bin/sh: 1: nodemon: not found
Jul 21 08:55:46 AM  error Command failed with exit code 127.
Jul 21 08:55:46 AM  info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I’m also disappointed by the speed at which support is responding to my private support request. I’m posting here because I haven’t heard anything particularly useful. I’m fairly sure random build failures have happened before and if I waited long enough it would just resolve itself. It’s been more than 16 hours at this point though and nothing’s changed. Here’s the full repository comparison between the last successful deploy and the current branch.

This all started with me trying to debug a minio issue, which, for what it’s worth is not resolved (my api is unable to access either a private minio instance or times out against a public one) and all has me looking at getting setup with Heroku instead.

[simonv3]

An update here is that when I tried to redeploy the last commit that successfully deployed (so I know that it worked at that point) the deploy failed with the same issue, which seems to tell me that it’s not an issue with the code, but possibly a configuration issue that changed somewhere.

[sauravhathi]

Why are you using nodemon for production use instead of devDependencies?

[simonv3]

Hey @sauravhathi, I’m not sure I understand your question, since the two sides of the “instead of” don’t seem like they’re exclusive.

Though, I know that running nodemon isn’t required in production, but when I switch to ts-node index.ts (my app is written in TypeScript) it is also unable to find ts-node in the same way. And note that both packages have been installed, I’ve tried both in devDependencies and dependencies.

And again, I want to emphasize that this used to work. Running the commit that deployed successfully in the past (and is currently live!) is using nodemon in devdependencies. Trying to deploy that commit again fails this time around, unable to find the packages needed.

[John_B]

I can see you have an existing support ticket open here so we’re kind of crossing threads here.

If nodemon is listed in devDependencies and Node is running in production mode then dev dependencies are not installed so nodemon will not be available.

I’d suggest getting it list in dependencies and then when you build try a manual build to clear the cache had deploy and see how that goes,

Regards,

John B
Render Support, UTC+1

[simonv3]

Hey John, thanks for the reply. The support ticket had a very slow response time so I decided to try here as well in case anyone could provide any insight.

I’d suggest getting it list in dependencies and then when you build try a manual build to clear the cache had deploy and see how that goes,

I had tried that here.

I got a reply via the support ticket just now that suggested removing the NODE_ENV from my environment variables as set through the Render UI (I’m a bit puzzled by how this got set, it’s very possible I did it manually myself at one point during all of this Edit: I think I did it while trying to get minio to work, which was the original issue).

Can you try removing the NODE_ENV environment variable on your service? We will automatically set this to production at runtime, but setting this manually will also set this value at build time, which will prevent your devdependencies, such as nodemon from installing.

I’m not fully clear on why this would still fail with the dependencies set in dependencies as they were in the aforementioned commit, but removing the NODE_ENV variable from the UI seems to have fixed the issue.