require() returns a Promise?!?

[wereHamster]

I have code where a call to require() returns a Promise. WTF? require calls are supposed to be synchronous, not return promises! This not only happens in client code, but also in getStaticProps on the server. Even when the path is completely static and known and resolvable at build time. When I replace the require() call with an import declaration it works.

The returned value has this shape:

Promise {
  Object [Module] {
    countryDimension: [Getter],
    dimensions: [Getter],
    fieldKeys: [Getter],
    fields: [Getter],
    source: [Getter]
  },
  [Symbol(async_id_symbol)]: 570009,
  [Symbol(trigger_async_id_symbol)]: 569994,
  [Symbol(destroyed)]: { destroyed: false },
  [Symbol(webpack exports)]: Object [Module] {
    countryDimension: [Getter],
    dimensions: [Getter],
    fieldKeys: [Getter],
    fields: [Getter],
    source: [Getter]
  },
  [Symbol(webpack then)]: [Function (anonymous)]
}

The stuff is there, correct, but wrapped in a promise.

Minimal project to reproduce issue, see this comment: #37520 (reply in thread)

[icyJoseph]

Well, require doesn't really exist on client side, so I guess some other library is taking over the require global definition, and replacing it with an asynchronous version.

At first I thought it'd be related to browserify, butI tried to reproduce, but I get no promise, only the module.

How does your package.json look like? Perhaps you are importing some scripts? polyfills? Or maybe you are doing something funny to the webpack config?

[wereHamster]

It does exist on the server though, in getStaticProps.

Here's a repro:

1. Clone the repo https://github.com/wereHamster/nextjs-require-promise
2. Install deps: npm install
3. Build: ./node_modules/.bin/next build

Observe how in the output is printed "getStaticProps Promise { … }", even though it's a regular require() call in the index page getStaticProps.

[icyJoseph]

It does exist on the server though, in getStaticProps.

It can still be messed with...

Here's a repro:

1. Clone the repo https://github.com/wereHamster/nextjs-require-promise
2. Install deps: npm install
3. Build: ./node_modules/.bin/next build

Observe how in the output is printed "getStaticProps Promise { … }", even though it's a regular require() call in the index page getStaticProps.

I get this log: require function is used in a way in which dependencies cannot be statically extracted - which is baffling.

Going back to the thesis of something overriding it, I think somehow webpack is deciding that because it cannot possibly resolve this dependency at build time, it ought to be dynamically loaded, which is why it turns it into a promise.

For example, if I do require('fs'), then it resolves nicely.

Is there any particular reason why you want to do require though? Next does code elimination to prevent server side stuff from leaking into the client, https://next-code-elimination.vercel.app/.

I'll try to read more about this, but since it is one of those webpack things that require, no pun intended, tons of reading, it might take me a while to get back.

I must also add that if I change your sdmx to export things defined inside the file, for example:

export const sum = (a, b) => a + b;

Then it works fine too, so I guess something about 'immer', is not letting webpack see beyond... so to speak.

[wereHamster]

Going back to the thesis of something overriding it, I think somehow webpack is deciding that because it cannot possibly resolve this dependency at build time, it ought to be dynamically loaded, which is why it turns it into a promise.

Hard to believe, the path that's being required is statically known, not dynamic in any way.

Is there any particular reason why you want to do require though? Next does code elimination to prevent server side stuff from leaking into the client, https://next-code-elimination.vercel.app/.

The repo is a gross simplification of a real project.

[icyJoseph]

I also added a few edits to my answer above.

I fixed it by going into sdmx and creating a package.json file there, with immer as a dependency, and now webpack is able to resolve require. Had to install it too...

Hard to believe, the path that's being required is statically known, not dynamic in any way.

Well believe it, the issue I think is that the way node_modules are resolved doesn't check sibling directories, but self and then to the parent, aka always resolve upwards, so immer cannot be resolved as far as webpack is concerned.

[hzroot]

I'm facing a quite similar issue where I conditionally require a package (for ssr), where require returns a promise. Any solutions?

[wereHamster]

Hm, replacing require() with a top-level import should work, assuming you have tree shaking properly set up in your project.

[anonrig]

Using a top-level import includes the schema in the browser too, with default next.js configurations. Any solutions for tree-shaking?

[wereHamster]

For tree-shaking to work in your code (as opposed to third-party code from node_modules), you have to put "sideEffects": false in your package.json. But even with that it's not guaranteed, and depends on babel (or swc).

[anonrig]

Thanks! That actually helped my problem.

[mqschwanda]

I am having the same exact problem as you @anonrig. I am trying to import my resolvers into a createIsomorphLink function for GraphQL SSR. When I import my resolvers I am getting errors because the mongodb package is being loaded into the client and throwing errors. It is important to note that when I import my database models into pages that leverage getServerSideProps or getStaticProps everything works without errors and the 'mongodb' module is not included in the client bundle, but as stated above when I import the same code into my createIsomorphLink function and use the code inside a typeof window === 'undefined' guard I am getting errors.

I tried to look at your changes for the enable tree-shaking commit, but the only relevant change I saw was updating "sideEffects": false in package.json. Unfortunately, this change did not help me as I am still getting errors and the 'mongodb' module is being loaded and breaks the client. Am I missing something in your updates, or was this really the only change that was needed to solve your issues?

The solution for me was to update the next.config.js file with a webpack configuration that ignores the 'mongodb' module on the client like so:

/** @type {import('next').NextConfig} */
module.exports = {
  webpack: (
    config,
    {
      isServer,
      webpack,
    },
  ) => {
    if (!isServer) {
      config.plugins.push(
        new webpack.IgnorePlugin({
          resourceRegExp: /mongodb$/,
        }),
      );
    }

    return config;
  },
};

This solution is not ideal for me because I still have server-side code leaking into my client bundle, but at least I can run the client without errors while still leveraging my current resolver pattern for SSR.

[mahhmoud-enzyme]

I just had the same issue. it seemed to not work on the server side, and work only on the client side, which is super effing weird.
I had to jump through loops to make the dynamic import work, especially cause I was importing an object in a file, not a component.

[CarlinCanales]

@mahhmoud-enzyme what hoops? i'm experiencing the exact same thing and i want to use dynamic import to also import an object, not a component.

[sgrund14]

I'm running into the same issue in my project, but the problem is when I'm trying to define a circular reference in my GraphQL schema

creators: createConnection({
            ...
            nodeType: require('../../identity/schemaTypes/UserType').UserType,
            ...
        }),

nodeType here is undefined, because the require returns a promise. Because this step is in the definition of the GraphQL schema, I can't get away with just awaiting the promise. It actually works in dev mode when I use a top level import, but the typescript starts to break on build, with an error like:
Type error: 'CollectionType' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

WTF !? anyone have any tips?

Context is that UserType has a field collections of CollectionType, and CollectionType has a field creator of type UserType.

[aMoniker]

@mqschwanda The circular reference is the reason I need to do the inline require.

https://vincit.github.io/objection.js/guide/relations.html#require-loops-non-ecmascript-modules-only

[mqschwanda]

I was responding to the message posted by @sgrund14

The issue doesn’t appear to be a circular dependency, but instead how the imports are built and handled.

The error posted by @sgrund14 during build is just a typescript error that can either be TS ignored or a ‘.d.ts’ file can be created to override types to what is expected. (Kinda hacky, but both solutions should work)

The other solution for @sgrund14 is to make sure all the types are in their own file without any executing code. This will allow you to import the file as types which will not throw the same circular dependency errors during runtime.

[sgrund14]

hey @aMoniker @mqschwanda

I ended up using the top level import instead of the require, which means me having to throw in a ts-ignore to fix ts error that appears

the circular reference itself is allowed in the graphql resolver when you declare fields as a function, rather than on object (something about evaluating the config at runtime I believe)

// circular reference allowed
fields: () => ({
    fieldDef: ...
})

// circular reference not allowed
fields: {
   fieldDef: ...
}

[mqschwanda]

@sgrund14 If you need to use functions to define your fields, why not just use require inside an async function and await the result?

You should be able to avoid the top level import altogether in your case

[sgrund14]

@mqschwanda bc fields does not accept an async function sadly