Next.js + pnpm + dgraph-js-http v20.07.2 = doesn’t work

Issues Dgraph Clients
,
1

So, I recently tried to integrate my Next.js app with the recently updated dgraph-js-http@20.07.2.

Here’s what I got:

1015×552 12.9 KB

From CLI:

SyntaxError: Unexpected token 'export'
    at wrapSafe (internal/modules/cjs/loader.js:979:16)
    at Module._compile (internal/modules/cjs/loader.js:1027:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.dgraph-js-http (C:\zz\next\aa\.next\server\pages\index.js:162:18)
    at __webpack_require__ (C:\zz\next\aa\.next\server\pages\index.js:23:31)
    at Module../pages/dgraph.js (C:\zz\next\aa\.next\server\pages\index.js:105:16)
C:\zz\next\aa\node_modules\.pnpm\dgraph-js-http@20.7.2\node_modules\dgraph-js-http\lib\index.js:1
export * from "./types";
^^^^^^

The reason might be due to the recent migration from CommonJS require to ES6 export through some JS files inside lib folder, particularly index.js with this GitHub commit:

Applying next-transpile-modules as suggested in a Next.js repo issue which seems to be related with the issue gave me this error instead:

internal/fs/utils.js:308
    throw err;
    ^

Error: ENOENT: no such file or directory, lstat 'C:\zz\next\aa\url'
    at realpathSync (fs.js:1728:7)
    at handleExternals (C:\zz\next\aa\node_modules\.pnpm\next@10.0.1_react-dom@17.0.1+react@17.0.1\node_modules\next\dist\build\webpack-config.js:68:21)
    at webpackConfig.externals (C:\zz\next\aa\node_modules\.pnpm\next@10.0.1_react-dom@17.0.1+react@17.0.1\node_modules\next\dist\build\webpack-config.js:80:136)
    at C:\zz\next\aa\node_modules\.pnpm\next-transpile-modules@4.1.0\node_modules\next-transpile-modules\src\next-transpile-modules.js:88:56
    at handleExternals (C:\zz\next\aa\node_modules\.pnpm\webpack@4.44.1\node_modules\webpack\lib\ExternalModuleFactoryPlugin.js:78:17)
    at next (C:\zz\next\aa\node_modules\.pnpm\webpack@4.44.1\node_modules\webpack\lib\ExternalModuleFactoryPlugin.js:66:9)
    at handleExternals (C:\zz\next\aa\node_modules\.pnpm\webpack@4.44.1\node_modules\webpack\lib\ExternalModuleFactoryPlugin.js:71:7)
    at C:\zz\next\aa\node_modules\.pnpm\webpack@4.44.1\node_modules\webpack\lib\ExternalModuleFactoryPlugin.js:101:5
    at C:\zz\next\aa\node_modules\.pnpm\webpack@4.44.1\node_modules\webpack\lib\NormalModuleFactory.js:400:5
    at AsyncSeriesWaterfallHook.eval [as callAsync] (eval at create (C:\zz\next\aa\node_modules\.pnpm\tapable@1.1.3\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:6:1) {
  errno: -4058,
  syscall: 'lstat',
  code: 'ENOENT',
  path: 'C:\\zz\\next\\aa\\url'
}
 ERROR  Command failed with exit code 1.

The only solution I have right now is downgrading the module to v20.07.1, which is working along properly with Next.js framework.

2

This is out of Dgraph’s scope, but here it goes.

Those are the tested dependencies:

    "dgraph-js-http": "^20.7.2",
    "next": "^10.0.1",
    "next-compose-plugins": "^2.2.0",
    "next-transpile-modules": "^4.1.0",
    "react": "17.0.1",
    "react-dom": "17.0.1"

Create a file called next.config.js at the root of your project.

Add this to your config file:

const withPlugins = require('next-compose-plugins');

const withTM = require('next-transpile-modules')(['dgraph-js-http']);

module.exports = withPlugins([
  [
    withTM
  ]
]);

Let me know if you still have issues.

Cheers.

3

Hm… that’s weird. It didn’t work for me. May I see your whole setup?

Update: After some inspection, turns out the issue here is pnpm (an alternative package manager) which I use regularly. Getting back to installing modules with npm resolves this error.

Thanks for the response, @MichelDiz. I’m gonna report this to pnpm GitHub repo. Not sure what to write, though. I still wish we don’t need this kind of workaround, just like the dgraph-js-http@20.07.1 one.

If anyone else managed to run the latest version with Next.js and pnpm properly, please share your solution here.

Update (2): The issue has been closed.

4

Hi, this isn’t just a problem with nextjs or pnpm. Switching from commonjs exports to esmodules is a breaking change for anyone using this library in node (without any extra transpilation steps like babel or typescript), and the fact that this happened in a patch release is incredibly dangerous (it nearly caused a production outage on our app, and we didn’t catch it before it took our QA infrastructure down).

1 Like
5

Hi, can you provide some examples of other implementation that happens such issues?

The transpile issue with NextJS is a common thing in their framework. Not all libs are made to always work with all frameworks. Some adjustments are always done in JS context. Since I started using JS I always had to adjust something in the way. That’s also one of the reasons that Babel exists.

Another example, is quite hard to move a pure webpack project to Parcel and so on. That’s a really common thing that you have to deal with in JS world.

If you help to improve compatibility with several frameworks and contexts, please contribute. We will appreciate it.

6

I appreciate your response, @nelsonpecora. While I’ve been doing this just for personal projects, this could be fatal for someone doing business or any other serious works.

And again, what’s the reason it had to be migrated from CommonJS to ES6? Does it have more features? Does it have better support? If I’m not mistaken, you still need to “toggle some switches” for ES Modules to work on Node.js below v13.

Currently, I have to fallback to regular GraphQL because of this. I couldn’t just ditch either Next.js or pnpm.

7

Hey, we are looking into it. Why this was migrated to ES6. Soon we gonna have a reason or a decision to revert this.

Cheers.

2 Likes
8

@MichelDiz thanks for the update here. We’ll be looking at this. I think it’s OK to use ES6 features like classes, etc, but we should ensure that we export things in a CommonJS compatible way.

1 Like
9

We’ve published a new release. @medriviaplease check if this is working?

2 Likes
10

Thank you so much, @gja and @MichelDiz . I just tried the new release and it’s working this time with Next.js and pnpm. No longer it needs to get set up with next-transpile-modules as well, which makes it easier to use compared to dgraph-js-http@20.07.2. I also looked up at the code and it seems the module has been reverted to CommonJS approach. Hopefully, that wasn’t much of a burden for you and the others working on it.

2 Likes