I get "Can't resolve '_http_common'" when I use NestJS with monorepo (webpack)

[kvandake]

Bug description

When I try to composite Prisma with NestJS monorepo project I get the error. I can`t use default prisma client output path because my projects use prisma client and each project overrides before generated client files. I try to use custom output path but I get the error. I found some information about the error -> restify/node-restify#794.

How to reproduce

Steps to reproduce the behavior:

1. Create new app as monorepo project
2. Generate client in custom output path. For example "output = ../src/prisma/client"
3. Execute command "build"
4. See error "Can't resolve '_http_common'"

Expected behavior

Build happy project

Environment & setup

• OS: Mac OS
• Database: PostgreSQL
• Node.js version: 12.22.1
• Prisma version: 2.21.2

datasource db {
  provider	=	"postgresql"
  url	=	env("MAIN_DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
  output = "../src/prisma/client"
}

[pantharshit00]

@kvandake Can you update your node js version to node 14 once?

[kvandake]

@pantharshit00 I try to use node 14.16.1 but I get same error.
I created a project with the bug.
https://github.com/kvandake/prisma-http-common-bug.
yarn build:my-app makes an error "Can't resolve '_http_common'".

[kvandake]

Node 16 does same error.

[kvandake]

I excluded _http_common from webpack. The build completed but when I start my project I get an error "_http_common is not defined". I created new branch master-webpack for reproduce this case.

webpack.config.js

module.exports = function(options) {
  return {
    ...options,
    target: 'node',
    externals: [...options.externals, '_http_common']
  };
};

[pantharshit00]

Ok, this looks like known issue #6564. I will recommend you downgrade while we work on a fix.

We are waiting for release of v4 of https://github.com/nodejs/undici which will remove the usage of _http_common private nodejs module altogether.

[LayneHaber]

I will recommend you downgrade while we work on a fix

Also seeing this -- are you suggesting a webpack or prisma downgrade?

[pantharshit00]

@LayneHaber I was suggesting to downgrade node js here to 14 LTS

[trivigy]

@LayneHaber @kvandake did you happen to find a workaround in the meantime? I tried running with node 14 LTS (per @pantharshit00 recommendation) but getting the same issue.

[j0hnm4r5]

@trivigy I'm in the same boat as you here — if you manage to find a workaround, please share. And I'll do the same!

[trivigy]

@j0hnm4r5 Unfortunately I do not know of a workaround and my current solution was to downgrade to prisma v2.20.0. In general I have the feeling that there is not going to be a fix until stable undici@v4 comes out.

[millsp]

Here's a temporary workaround, to add to your next.config.js. Sorry for the inconvenience, we will upgrade undici asap. You might need to exclude encoding too, so I'll let you uncomment that if needed.

module.exports = {
    webpack: (config, {isServer}) => {
        if (isServer) {
            config.externals.push('_http_common');
			// config.externals.push('encoding');
        }
        return config;
    },
    target: 'serverless',
};

[j0hnm4r5]

@millsp that got me closer, but still no cigar. I'm not sure if it's a Prisma, Next-Auth, or my issue at this point though: #7311

I can import the client okay, and even console.log it perfectly fine before setting the adapter, but once it is in the adapter, those errors start to throw. Any ideas?

[millsp]

Hey @j0hnm4r5, sorry to hear that. Could you find some time to work on a minimal repro, I'll be more than happy to look into it.

[j0hnm4r5]

@millsp here's a reproduction repo that clearly shows what's going on (with instructions): https://github.com/j0hnm4r5/example-prisma-next-auth-monorepo

I really appreciate all your help!

[j0hnm4r5]

@millsp any luck, by chance?

[LayneHaber]

Also sad to report that I didn't find a workaround other than not upgrading prisma or webpack 😢

But it does look like v4 of unidici is in release candidate stages

[ahmadalfy]

Any update on this? I am facing this with version 3.1 as well

[millsp]

Hey @ahmadalfy, sorry about this. We have a fix ready but that is unfortunately blocked due to memory leak issues. That will need to be prioritized first (and investigated) before we can merge the fix.

[ahmadalfy]

@millsp thanks for the update, I found a work around because I use Nx so all references to Prisma moved to the library of components instead of the nest application.

[homoky]

For me is working to get client generated as below:

generator client {
  provider        = "prisma-client-js"
  output          = "../../../node_modules/@~internal/prisma"
}

Then you can import it from anywhere like:

import {PrismaClient} from '@~internal/prisma'

Hope it helps.

[juanzgc]

I'm using Turborepo and I'm also facing the same issues.

Prisma Version: 3.10.0
Next Version: 12.0.8

It seems when I import prisma from a package in my turborepo nextjs app I get the following error:

Module not found: Can't resolve '_http_common'

[vincent-thomas]

I still have this issue error

ERROR in ./apps/thunderbolt/prisma/client/runtime/index.js 27999:21-44
Module not found: Error: Can't resolve '_http_common' in 'C:\Users\vincent\coding\Codebase\apps\thunderbolt\prisma\client\runtime'

[juanzgc]

Do you have a timeline for the following issue: #8842

It would be great to have this sorted so we can begin using Prisma in our monorepo (Turborepo)! 😇

[millsp]

Hey everyone, this has been fixed in @prisma/client@dev if you want to give it a try. Please let us know if you find anything unexpected. Thanks.

(cc @VincentThomas06 @j0hnm4r5 @juanzgc)

[vincent-thomas]

Hey everyone, this has been fixed in @prisma/client@dev if you want to give it a try. Please let us know if you find anything unexpected. Thanks.

(cc @VincentThomas06 @j0hnm4r5 @juanzgc)

Thanks for notifying me!

[Frankitch]

In my case, I am not getting the Can't resolve '_http_common' error anymore but now I am getting a Can't resolve 'util/types' error.

To reproduce it, I started from this prisma blog post project as a base + @prisma/client upgrade to 3.11.0 and dev + set a custom output path.

[vincent-thomas]

In my case, I am not getting the Can't resolve '_http_common' error anymore but now I am getting a Can't resolve 'util/types' error.

To reproduce it, I started from this prisma blog post project as a base + @prisma/client upgrade to 3.11.0 and dev + set a custom output path.

Thats funny, i got the same error:

ERROR in ./prisma/client/runtime/index.js 33781:27-48
Module not found: Error: Can't resolve 'util/types' in 'C:\Users\vincent\coding\Codebase\apps\thunderbolt\prisma\client\runtime'
resolve 'util/types' in 'C:\Users\vincent\coding\Codebase\apps\thunderbolt\prisma\client\runtime'
  Parsed request is a module
  using description file: C:\Users\vincent\coding\Codebase\apps\thunderbolt\package.json (relative path: ./prisma/client/runtime)

webpack config:

module.exports = (options, webpack) => {
  const lazyImports = [
    '@nestjs/microservices/microservices-module',
    '@nestjs/websockets/socket-module',
// Tried fixing the issue with this below
    /util/
  ];

  return {
    ...options,
    externals: ['util'],

    resolve: {
      extensions: ['.ts', '.js', '.json'],
      fallback: {
        util: require.resolve('util/')
      }
    },
    module: {
      rules: [
        {
          test: /\.ts$/,
          use: 'ts-loader'
        },
        {
          test: /\.js$/,
          exclude: /(node_modules|prisma)/,
          use: {
            loader: 'swc-loader'
          }
        }
      ]
    },
    plugins: [
      ...options.plugins,
      new webpack.IgnorePlugin({
        checkResource: resource => {
          if (lazyImports.includes(resource)) {
            try {
              require.resolve(resource);
            } catch (err) {
              return true;
            }
          }
          return false;
        }
      })
    ]
  };
};

[millsp]

Hey @Frankitch @VincentThomas06 👋 I think I understood the issue. When you generate to the default location, the client gets generated with a package.json in which there is a browser field. This field is used by webpack to bundle for the web (default). But because it's generated outside of node_modules, we don't create such package.json. Maybe for good reasons? Maybe not?

The next steps will simple. I'll need to setup a repro, you're very welcome to help me there if you already have one. And that is just to make sure we are fixing the right problem. Then, I will let us output a package.json in custom locations to and see if webpack/nestjs can pick that up automatically. If that fails, I will provide you with a workaround.

Thus, I'm closing this issue about _http_common, but don't worry we will be tracking the work to come via #12607

Thanks!

[joshribakoff-sm]

@millsp I think you got it wrong. In my project I am generating a client in the node_modules, it works 50% of the time and the other 50% I get the error described in this issue. When it does work, I inspect the built artifacts and there is no package.json. This doesn't seem related to a package.json or generating clients outside of node_modules

I verified the problematic line is in fact there during the times it works::

grep -r 'http_common' node_modules/@internal/prisma
node_modules/@internal/prisma/client/runtime/index.js:    var common = require("_http_common");

this is also a file that doesn't exist in my project (both when Prisma fails to be generated, and in the cases where Prisma generation is scuffed):

find . | grep http_common
# no output

[millsp]

http_common imports should all be gone in the latest versions of prisma, as that was coming from our undici dependency. Which version are you testing this on?

[joshribakoff-sm]

You're right, I had to update @prisma/client to 3.15.2 (and not just prisma as I had done previously), and it is working now 👍