Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

next build fails with "Module did not self-register." #7894

Closed
Vista1nik opened this issue Jul 11, 2019 · 56 comments · Fixed by #8290 or #9199
Closed

next build fails with "Module did not self-register." #7894

Vista1nik opened this issue Jul 11, 2019 · 56 comments · Fixed by #8290 or #9199
Assignees
Milestone

Comments

@Vista1nik
Copy link

Vista1nik commented Jul 11, 2019

Bug report

Describe the bug

next build fails with following error after upgrade to Next 9.

{ Error: Module did not self-register.
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:857:18)
    at Module.load (internal/modules/cjs/loader.js:685:32)
    at Function.Module._load (internal/modules/cjs/loader.js:620:12)
    at Module.require (internal/modules/cjs/loader.js:723:19)
    at require (internal/modules/cjs/helpers.js:14:16)
    at Object.<anonymous> (/home/vista1nik/Documents/nextjs-project/node_modules/grpc/src/grpc_extension.js:32:13)
    at Module._compile (internal/modules/cjs/loader.js:816:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
    at Module.load (internal/modules/cjs/loader.js:685:32)
    at Function.Module._load (internal/modules/cjs/loader.js:620:12) type: 'Error', '$error': '$error' }

Error happens after compilation.
Last Build trigger before error is:
https://github.com/zeit/next.js/blob/5a54e8715a7a7a92175addc19f4ec9f8f7bbd2e7/packages/next/build/index.ts#L342

To Reproduce

https://github.com/jpbow/module-register-build-issue

Expected behavior

next build success

System information

  • OS: Arch Linux
  • Version of Next.js: 9.0.0

Additional context

Tried yarn install --forceand Clean depends install.

next . dev-command work properly.

@timneutkens
Copy link
Member

Please provide a full reproduction

@Vista1nik
Copy link
Author

I'll provide reproduction tomorrow. Today I don't have access to my pc.

@Vista1nik
Copy link
Author

Close because it's firebase grpc problem.

@Vista1nik
Copy link
Author

There is similar problem in #7821

@go-rani
Copy link

go-rani commented Jul 13, 2019

Close because it's firebase grpc problem.

How can i fixed it?
I have same problem

@Vista1nik
Copy link
Author

@go-rani Currently I don't have a solution because I not fully sure that this problem belongs to firebase. I trying to reproduce this bug in example project.

@vbilici
Copy link

vbilici commented Jul 15, 2019

I have the same problem. It goes normal when I downgrade to v8
here is the image I am using:
gcr.io/google_appengine/nodejs

@Vista1nik
Copy link
Author

@vbilici interesting...

@Vista1nik Vista1nik reopened this Jul 15, 2019
@vbilici
Copy link

vbilici commented Jul 15, 2019

I have a feeling that it's caused by newly added build report. Because the error throws after build completes

Creating an optimized production build ...

> Using external babel configuration
> Location: "/app/.babelrc"
Compiled successfully.

Warning: You have opted-out of Automatic Prerendering due to `getInitialProps` in `pages/_app`.
Read more: https://err.sh/next.js/opt-out-automatic-prerendering

> Build error occurred
{ Error: Module did not self-register.
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:730:18)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.<anonymous> (/app/node_modules/@firebase/firestore/node_modules/grpc/src/grpc_extension.js:32:13)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32) type: 'Error', '$error': '$error' }
error Command failed with exit code 1.

@partykyoung
Copy link
Contributor

I'm having same issue.

But when I comment out 'import firebase/firestore', this issue did'nt happen.

import firebase from 'firebase/app';
import 'firebase/auth';
import 'firebase/functions';
import 'firebase/database';
// import 'firebase/firestore'; <-- 

But I need firebase/firestore. this is not solution.

@Vista1nik
Copy link
Author

As I understand any dependency with grpc breaking nextjs build?

@ch4rlesyeo
Copy link

ch4rlesyeo commented Jul 17, 2019

Getting this issue as well.

I was able to build at first, but it happens when my /pages grown big. I tried reverting back to an old commit where i can build without issue and duplicate my /pages folder (-v1, -v2 and so on) build after build to a point where it fails.

I couldn't quantify how "big" is big but hope this helps.

@jpbow
Copy link

jpbow commented Jul 19, 2019

@timneutkens @Vista1nik I've created a reproduction here https://github.com/jpbow/module-register-build-issue

@Vista1nik
Copy link
Author

@jpbow Thanks for repoduction, added to issue.

@Pushplaybang
Copy link

just chiming in, this also fails when deploying with now 2.0

@Vista1nik
Copy link
Author

It's seems like NextJS 9 is incompatible with dependencies which use GRPC in anyway.
Currently I trying to find any other package which use GRPC to confirm that.

@Pushplaybang
Copy link

@Vista1nik it'll fail with both firebase and gcp. Both use grpc.

@Pushplaybang
Copy link

after updating my next.config.js with the following (as mentioned in #6073 )

 webpack(config, options) {
    if (process.env.NODE_ENV !== "development") {
      config.externals = {
        grpc: "grpc"
      };
    }
    return config;
  }

link: #6073 (comment)

My deployment error has changed, I don't think this is optimal but may be a temporary workaround for others who are trying to update production builds

the new error seems related to AMP toolbox,

running "yarn run now-build"
Jul 22 2019 14:05:48:345 | ...next.config.js | yarn run v1.16.0
Jul 22 2019 14:05:48:403 | ...next.config.js | $ next build
Jul 22 2019 14:05:49:159 | ...next.config.js | Creating an optimized production build ...
Jul 22 2019 14:05:49:824 | ...next.config.js | > Using external babel configuration
Jul 22 2019 14:05:49:824 | ...next.config.js | > Location: "/tmp/bc0fa1c/babel.config.js"
Jul 22 2019 14:07:52:235 | ...next.config.js | Failed to compile.
Jul 22 2019 14:07:52:235 | ...next.config.js | ./node_modules/amp-toolbox-optimizer/lib/transformers/AddBlurryImagePlaceholders.js
Jul 22 2019 14:07:52:235 | ...next.config.js | Module not found: Can't resolve 'jimp' in '/tmp/bc0fa1c/node_modules/amp-toolbox-optimizer/lib/transformers'
Jul 22 2019 14:07:52:235 | ...next.config.js |  

which is annoying as I'm not using AMP at all, not sure how related this is but hopefully its helpful.

@jayb967
Copy link

jayb967 commented Aug 4, 2019

I am having the same issue using firebase.. Has anyone found a deployment workaround?

@mglonnro
Copy link

mglonnro commented Aug 8, 2019

For some reason building my project on mac OS works, while on Debian I get the same "Module did not self-register" error.

@z3r0c00l-2k
Copy link

Did anyone found any workaround for this issue?

@Vista1nik
Copy link
Author

There must be joke about "Buy new Mac".
Currently only downgrade is solution.

@timneutkens timneutkens added this to the 9.0.x milestone Aug 8, 2019
@timneutkens timneutkens assigned ijjk and Timer and unassigned ijjk Aug 8, 2019
@notiles
Copy link

notiles commented Oct 23, 2019

Try to remove this import : import "firebase/firestore"; only in index.js

@ctavan
Copy link
Contributor

ctavan commented Oct 25, 2019

@notiles if you remove one of the two firebase/firestore imports then you are no longer provoking a parallel build of two modules that require grpc.

As mentioned above I'm pretty confident that the issue we are observing here is caused by grpc/grpc-node#778 which states that grpc "Does not support multiple threads".

As a workaround I figured out that builds succeed with the following next.config.js:

module.exports = {
  experimental: {
    cpus: 1,
  },
};

and fail as soon as you increase the CPU count (which further proves that parallel worker execution is the root cause). Obviously builds will then no longer take advantage of multiple worker threads, so this is a workaround, not a solution.

@ijjk, @Timer, @timneutkens sorry for bugging you again: how would you deal with this issue?

@notiles
Copy link

notiles commented Oct 25, 2019

It's clear @ctavan ! Thanks a lot for this explanation. Unfortunately I still have the issue with experimental: {
cpus: 1,
}

`Warning: You have enabled experimental feature(s).
Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use them at your own risk.

Using external babel configuration
Location: "/Users/me/myproject/.babelrc"
Creating an optimized production build

Compiled successfully.

Automatically optimizing pages ..
Error occurred prerendering /download/[document_id]: Error: Failed to load /Users/me/myproject/node_modules/grpc/src/node/extension_binary/node-v72-darwin-x64-unknown/grpc_node.node. Module did not self-register.

etc...`

I switch form Node 11.9.0 to Node 10.12 and Node 13.0.1 to Node 12.13.0 without success...

@ctavan
Copy link
Contributor

ctavan commented Oct 25, 2019

I was a bit too quick. With the next.config.js from my previous comment the build did work for f81b6d5 but not with next@9.1.1 because 61b8b73 introduced jest-worker to next export which is called as part of the build step.

My initial idea was to pass the config.experimental.cpus on to the export worker, however I did not succeed. Even with setting numWorkers: 1 the export step in the build will fail with the Module did not self-register. error.

The only way of getting it to work for my use case was setting enableWorkerThreads: false in:

https://github.com/zeit/next.js/blob/a964dc825ecea1e35fb460184828974e00b7d6d6/packages/next/export/index.ts#L265-L273

A possible workaround could be to allow setting config.experimental.cpus: 0 and as a consequence disabling worker threads altogether. I will provide a Pull Request for this suggestion shortly.

@notiles
Copy link

notiles commented Oct 25, 2019

Ok @ctavan ! That's totally true, I change enableWorkerThreads to false and build succeed with next 9.1.1

So finally it's more a grpc issue than a next issue ? What's your feeling about that ? Do you think that we have to open an issue on grpc ?

Thanks a lots for all your explanations that's really helpfull.

ctavan added a commit to ctavan/next.js that referenced this issue Oct 25, 2019
Multiple worker threads can cause problems when certain dependencies are
being used, see e.g. vercel#7894

This patch allows disabling of worker threads by setting
`config.experimental.cpus = 1`.

The benefit of spawning 1 worker thread, if there is any at all, should
very limited anyways, so the workload can just as well be processed in
the main thread.
@ctavan
Copy link
Contributor

ctavan commented Oct 25, 2019

I have now proposed #9199 where setting config.experimental.cpus: 1 will disable worker threads altogether. This makes next build succeed for all use cases that involve grpc and that I have tested.

For me, that would be an acceptable workaround until the issue is fixed in grpc or firebase. There is already an issue in the grpc repo (grpc/grpc-node#778) but apparently the solution depends on upstream changes in node (nodejs/nan#844).

I now believe that this is something that rather needs to be fixed in grpc, not here. At least I don't see a straightforward way of fixing it in Next.js without going back to older parallelization technology which would definitely hurt the codebase.

If #9199 gets accepted we would at least have a way to build projects that depend on firebase/firestore, even though build times might be longer since we cannot make use of parallelism.

ctavan added a commit to ctavan/next.js that referenced this issue Oct 25, 2019
Multiple worker threads can cause problems when certain dependencies are
being used, see e.g. vercel#7894

This patch allows disabling of worker threads by setting
`config.experimental.cpus = 1`.

The benefit of spawning 1 worker thread, if there is any at all, should
very limited anyways, so the workload can just as well be processed in
the main thread.
ctavan added a commit to ctavan/next.js that referenced this issue Oct 28, 2019
Multiple worker threads can cause problems when certain dependencies are
being used, see e.g. vercel#7894

This patch allows disabling of worker threads by setting
`config.experimental.cpus = 1`.

The benefit of spawning 1 worker thread, if there is any at all, should
very limited anyways, so the workload can just as well be processed in
the main thread.
ctavan added a commit to ctavan/next.js that referenced this issue Oct 28, 2019
Timer pushed a commit that referenced this issue Oct 29, 2019
* Pass config.experimental.cpus to export during build

Currently, there is no way of specifying the number of worker threads of
`next export` when run as part of `next build`.

I suggest a sane default should be to just use the same amount of
workers that were used during the build process which currently seems to
be configured through `config.experimental.cpus`.

This setting is already respected in the two other places where
jest-workers are in use: The TerserPlugin and the staticCheckWorkers in
`next build`.

* Only enable worker threads if there is more than 1 worker

Multiple worker threads can cause problems when certain dependencies are
being used, see e.g. #7894

This patch allows disabling of worker threads by setting
`config.experimental.cpus = 1`.

The benefit of spawning 1 worker thread, if there is any at all, should
very limited anyways, so the workload can just as well be processed in
the main thread.

* Disable parallel build for firebase authentication example

* Add integration test to cover #7894

* Rename test suite and add worker_threads config

* Disable worker_threads by default

* Update index.test.js

* Use workerThreads config for TerserPlugin

* Update to use workerThreads config in
TerserPlugin for consistency

* Disable node 12 specific test
satazor added a commit to moxystudio/next-intl that referenced this issue Nov 22, 2019
The canvas package, which is a dependency of jsdom, has a native binding which causes the following error during Next.js build process: "Module did not self-register".
We circuvent that by using a null-loader.
See vercel/next.js#7894

The ws package, which is also a dependency of jsdom, tries to optionally load some dependencies.
This produces a warning in webpack that we want to avoid.
We circuvent that by adding them to externals.
satazor added a commit to moxystudio/next-intl that referenced this issue Nov 22, 2019
The canvas package, which is a dependency of jsdom, has a native binding which causes the following error during Next.js build process: "Module did not self-register".
We circuvent that by using a null-loader.
See vercel/next.js#7894

The ws package, which is also a dependency of jsdom, tries to optionally load some dependencies.
This produces a warning in webpack that we want to avoid.
We circuvent that by adding them to externals.
satazor added a commit to moxystudio/next-intl that referenced this issue Nov 22, 2019
The canvas package, which is a dependency of jsdom, has a native binding which causes the following error during Next.js build process: "Module did not self-register".
We circuvent that by using a null-loader.
See vercel/next.js#7894

The ws package, which is also a dependency of jsdom, tries to optionally load some dependencies.
This produces a warning in webpack that we want to avoid.
We circuvent that by adding them to externals.
ivolimasilva pushed a commit to moxystudio/next-intl that referenced this issue Nov 22, 2019
The canvas package, which is a dependency of jsdom, has a native binding which causes the following error during Next.js build process: "Module did not self-register".
We circuvent that by using a null-loader.
See vercel/next.js#7894

The ws package, which is also a dependency of jsdom, tries to optionally load some dependencies.
This produces a warning in webpack that we want to avoid.
We circuvent that by adding them to externals.
@CesarArdilaB
Copy link

HEY EVERYBODY!
Just Add

"engines": {
"node": "10.x"
}

To your package.json

You are welcome coders.

@mattburman
Copy link

for anyone else who was tracking this issue:

I can confirm I no longer get "Module did not self-register" when using grpc.
v9.3.2 includes #11347 which is what fixed it

@its-dibo
Copy link

I have the same error

repo
building error

Error: Error occurred while parsing your function triggers.

Error: 
Something went wrong installing the "sharp" module

Module did not self-register.

@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet