Running 'nuxt build' when '@prisma/nuxt' is listed in the modules in nuxt.config deletes other nuxt modules

[david-mears-2]

Versions

"@prisma/client": "^5.17.0"
"@prisma/nuxt": "^0.0.30"
"nuxt": "^3.12.3",
"prisma": "^5.17.0",

Issue

Running the dev server works fine. Running nuxt build (via npm run build) when @prisma/nuxt is listed in the modules in nuxt.config.ts deletes other nuxt modules from node_modules/@nuxt, leading to errors such as:

Error while requiring module @nuxt/devtools: Error: Cannot find module '@nuxt/devtools'

or '@nuxt/test-utils', etc: the first module that fails to be found depends on the order in which modules are listed in nuxt.config.ts.

Before running npm run build, the nuxt part of my node_modules looked like this:

After running npm run build, which errored as above, the nuxt part of my node_modules looked like this:

This uninstalled or deleted a lot of nuxt modules, such that for example trying to run npm run build immediately afterwards led to:

npm run build

> build
> nuxt build

sh: 1: nuxt: not found

The other modules listed in my nuxt.config.ts are:

modules: [
    "@nuxtjs/fontaine",
    "@pinia/nuxt",
    "@nuxt/test-utils/module",
    "@nuxt/eslint",
    "@nuxtjs/i18n",
  ],

Possible workaround?

My workaround is to not use @prisma/nuxt.

I found that I could run the build step and it did not delete nuxt modules, and I could still use prisma (at least, I could perform operations from within an api endpoint, as below) if I uninstalled @prisma/nuxt, omitted the module from nuxt.config.ts, and used 'usage option B' instead of the composable.

import prisma from "~/lib/prisma";

export default defineEventHandler(async (event) => {
  const uniqueString = Math.random().toString(36).substring(7);

  await prisma.user.create({
    data: {
      email: `${uniqueString}@email.com`,
      name: "Hello",
    },
  });

  // Return all users
  return {
    user: await prisma.user.findMany(),
  };
});

# package.json
...
  "devDependencies": {
    "@antfu/eslint-config": "2.21.0",
    "@nuxt/eslint": "^0.3.13",
    "@nuxt/test-utils": "^3.13.1",
    "@nuxtjs/i18n": "^8.3.1",
    "@playwright/test": "^1.45.1",
    "@prisma/client": "^5.17.0",
    "@types/lodash.throttle": "^4.1.9",
    "@types/node": "^20.14.9",
    "@vitest/coverage-v8": "^1.6.0",
    "@vue/test-utils": "^2.4.6",
    "jsdom": "^24.1.0",
    "lint-staged": "^15.2.7",
    "nuxt": "^3.12.3",
    "prisma": "^5.17.0",
    "sass": "^1.77.6",
    "simple-git-hooks": "^2.11.1",
    "vitest": "^1.6.0"
  },

[Harm-Nullix]

Same issue, this is so lame :P

https://github.com/prisma/nuxt-prisma/blob/main/src/module.ts#L85 Also causes optimizeDepths to be totally rewritten.

This Module assumes more things like:

• settings experimental options: https://github.com/prisma/nuxt-prisma/blob/main/src/module.ts#L74
• exposing use of prisma to the frontend: https://github.com/prisma/nuxt-prisma/blob/main/src/module.ts#L97

In current state, would not recommend using this module. (sorry for the bash, I know people work hard on this but it just isn't production worthy for my 2cents )

[ankur-arch]

Hey @Harm-Nullix, thanks for reporting the issue.

I understand your frustration and appreciate your feedback. Could you provide a reproduction so I can better investigate the problem?

Regarding the assumptions you mentioned:

Experimental Settings: [main/src/module.ts#L74](https://github.com/prisma/nuxt-prisma/blob/main/src/module.ts?rgh-link- date=2024-08-09T08%3A43%3A09Z#L74) Frontend Exposure: [main/src/module.ts#L97](https://github.com/prisma/nuxt-prisma/blob/main/src/module.ts?rgh-link- date=2024-08-09T08%3A43%3A09Z#L97)

I appreciate you pointing these out. We’re planning further improvements, but these particular assumptions may not be directly related to the current issue. Could you create a separate issue for these points? This will help me address them more effectively.

[BlueBazze]

Could you provide a reproduction so I can better investigate the problem?

Im sorry i dont mean to be rude or anything in that direction. You need a reproduction to see that the module is overriding entire nuxt.options.vite.optimizeDeps? https://github.com/prisma/nuxt-prisma/blob/main/src/module.ts#L87-L89 If nuxt.options.vite.optimizeDeps has any value before this module is set up it will get deleted. If the user uses this key in their nuxt.config.ts it will get overridden.

You can either run .push or just throw defu at it

      nuxt.options.vite.optimizeDeps = defu(nuxt.options.vite.optimizeDeps, {
        include: ["@prisma/nuxt > @prisma/client"],
      });

The assumption regarding the exposure to the runtimeConfig. nuxt.options.runtimeConfig.public.prisma exposes to the frontend. nuxt.options.nitro.runtimeConfig.public.prisma exposes only to server side.

[xinconan]

Same issue. It doesn't seem to have been repaired.

[nonhana]

Me too.I'm now using the author's method to solve this problem temporarily and it works.