Error: Module did not self-register #1895

MLoughry · 2017-02-13T00:47:49Z

I'm in the process of upgrading my team's project to webpack 2, and I'm now encountering numerous "Module did not self-register" errors for .scss files, both locally and in our build system. Example errors for one file:

ERROR in c:/Agents/01/_work/1/s/obj/framework/owa-application/lib/styles/globalstyles.global.scss
Module build failed: ModuleBuildError: Module build failed: Error: Module did not self-register.
    at Error (native)
    at Object.Module._extensions..node (module.js:597:18)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at module.exports (C:\Agents\01\_work\1\s\node_modules\node-sass\lib\binding.js:19:10)
    at Object.<anonymous> (C:\Agents\01\_work\1\s\node_modules\node-sass\lib\index.js:14:35)
    at Module._compile (module.js:570:32)
    at C:\Agents\01\_work\1\s\node_modules\webpack\lib\NormalModule.js:141:35
    at C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\LoaderRunner.js:364:11
    at C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\LoaderRunner.js:170:18
    at loadLoader (C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\loadLoader.js:27:11)
    at iteratePitchingLoaders (C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\LoaderRunner.js:169:2)
    at iteratePitchingLoaders (C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\LoaderRunner.js:165:10)
    at C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\LoaderRunner.js:173:18
    at loadLoader (C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\loadLoader.js:36:3)
    at iteratePitchingLoaders (C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\LoaderRunner.js:169:2)
    at iteratePitchingLoaders (C:\Agents\01\_work\1\s\node_modules\loader-runner\lib\LoaderRunner.js:165:10)�

ERROR in C:\Agents\01\_work\1\s\node_modules\extract-text-webpack-plugin\loader.js??ref--1-0!C:\Agents\01\_work\1\s\node_modules\style-loader\index.js!C:\Agents\01\_work\1\s\node_modules\css-loader\index.js?minimize!C:\Agents\01\_work\1\s\node_modules\postcss-loader\index.js??ref--1-3!C:\Agents\01\_work\1\s\node_modules\sass-loader\lib\loader.js!c:\Agents\01\_work\1\s\obj\framework\owa-application\lib\styles\globalstyles.global.scss doesn't export content�

ERROR in C:\Agents\01\_work\1\s\node_modules\extract-text-webpack-plugin\loader.js??ref--1-0!C:\Agents\01\_work\1\s\node_modules\style-loader\index.js!C:\Agents\01\_work\1\s\node_modules\css-loader\index.js?minimize!C:\Agents\01\_work\1\s\node_modules\postcss-loader\index.js??ref--1-3!C:\Agents\01\_work\1\s\node_modules\sass-loader\lib\loader.js!c:\Agents\01\_work\1\s\obj\framework\owa-application\lib\styles\globalstyles.global.scss doesn't export content�

ERROR in C:\Agents\01\_work\1\s\node_modules\extract-text-webpack-plugin\loader.js??ref--1-0!C:\Agents\01\_work\1\s\node_modules\style-loader\index.js!C:\Agents\01\_work\1\s\node_modules\css-loader\index.js?minimize!C:\Agents\01\_work\1\s\node_modules\postcss-loader\index.js??ref--1-3!C:\Agents\01\_work\1\s\node_modules\sass-loader\lib\loader.js!c:\Agents\01\_work\1\s\obj\framework\owa-application\lib\styles\globalstyles.global.scss doesn't export content�

ERROR in C:\Agents\01\_work\1\s\node_modules\extract-text-webpack-plugin\loader.js??ref--1-0!C:\Agents\01\_work\1\s\node_modules\style-loader\index.js!C:\Agents\01\_work\1\s\node_modules\css-loader\index.js?minimize!C:\Agents\01\_work\1\s\node_modules\postcss-loader\index.js??ref--1-3!C:\Agents\01\_work\1\s\node_modules\sass-loader\lib\loader.js!c:\Agents\01\_work\1\s\obj\framework\owa-application\lib\styles\globalstyles.global.scss doesn't export content�
    
Child �extract-text-webpack-plugin�:
ERROR in ./~/css-loader?minimize!./~/postcss-loader?{"plugins":[null,null]}!./~/sass-loader/lib/loader.js!c:/Agents/01/_work/1/s/obj/framework/owa-application/lib/styles/globalstyles.global.scss
    Module build failed: Error: Module did not self-register.
        at Error (native)
        at Object.Module._extensions..node (module.js:597:18)
        at Module.load (module.js:487:32)
        at tryModuleLoad (module.js:446:12)
        at Function.Module._load (module.js:438:3)
        at Module.require (module.js:497:17)
        at require (internal/module.js:20:19)
        at module.exports (C:\Agents\01\_work\1\s\node_modules\node-sass\lib\binding.js:19:10)
        at Object.<anonymous> (C:\Agents\01\_work\1\s\node_modules\node-sass\lib\index.js:14:35)
        at Module._compile (module.js:570:32)

When I search for the error, I find issues opened ~2 years ago that have all allegedly been fixed since, but nothing more recently. I've followed the Troubleshooting guide, and tried such suggestions as doing a clean npm install (which our build system does anyway) and running npm rebuild, to no avail.

NPM version (npm -v): 3.10.10
Node version (node -v): v6.9.5
Node Process (node -p process.versions):

    { http_parser: '2.7.0',
      node: '6.9.5',
      v8: '5.1.281.89',
      uv: '1.9.1',
      zlib: '1.2.8',
      ares: '1.10.1-DEV',
      icu: '57.1',
      modules: '48',
      openssl: '1.0.2k' }

Node Platform (node -p process.platform): win32
Node architecture (node -p process.arch): x64
node-sass version (node -p "require('node-sass').info"):

node-sass       4.5.0   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]

npm node-sass versions (npm ls node-sass): [email protected]

The text was updated successfully, but these errors were encountered:

xzyfer · 2017-02-13T01:03:51Z

This error suggest that the binary you have installed does not match your current environment. If you run the following you should see a win32-x64-48 folder.

dir node_modules\node-sass\vendor

This usually happens the node version is changed between npm install and executing your code. When this happens you need to rebuild native extensions with npm rebuild.

MLoughry · 2017-02-13T01:10:47Z

As stated previously, I had already run npm rebuild.

PS B:\VSO\owa-mail> dir node_modules\node-sass\vendor


    Directory: B:\VSO\owa-mail\node_modules\node-sass\vendor


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        2/12/2017   4:20 PM                win32-x64-48

xzyfer · 2017-02-13T01:30:59Z

Hmm we changed the way the windows binaries were build in 4.5.0. Can you try 4.4.0 to rule that out?

MLoughry · 2017-02-13T01:48:31Z

Sorry, same issue in 4.4.0. :(

xzyfer · 2017-02-13T02:09:42Z

The error suggests the binary is broken. Can you replacing the binary in the vendor folder with the one from the GitHub release

…

On 13 Feb. 2017 12:48 pm, "Michael Loughry" ***@***.***> wrote: Sorry, same issue in 4.4.0. :( — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1895 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWAVZoPp0pNHgWTC0X3__4wX1Ze4Gks5rb7ZvgaJpZM4L-seP> .

MLoughry · 2017-02-13T02:15:10Z

Same issue when I replace node_modules\node-sass\vendor\win32-x64-48\binding.node with the file from the 4.4.0 release (https://github.com/sass/node-sass/releases/download/v4.4.0/win32-x64-48_binding.node)

xzyfer · 2017-02-13T02:33:12Z

The error appears to be environmental. There's something about how you're using webpack/node-sass that is causing the issue.

How are you executing webpack?

What's the full output of npm ls node-sass?

Which loader are you using for node-sass?

MLoughry · 2017-02-13T02:51:29Z

How are you executing webpack?

We're returning a webpack compiler instance from a gulp task (Typescript code below):

gulp.task('build:webpack', function (done: Function) {
    // returns a Compiler instance
    return webpack(
        webpackConfig(),
        function (err: Error, stats: any) {
            if (err) {
                return done(err);
            }

            if (stats.hasErrors()) {
                return done(stats.toString("errors-only"));
            }

            return done();
        });
});

What's the full output of npm ls node-sass?

PS B:\VSO\owa-mail> npm ls node-sass
[email protected] B:\VSO\owa-mail
`-- [email protected]
  +-- [email protected]
  `-- UNMET PEER DEPENDENCY [email protected]

npm ERR! peer dep missing: webpack@^1.9.11, required by [email protected]

Which loader are you using for node-sass?

[email protected]

xzyfer · 2017-02-13T12:26:12Z

I don't really know how to progress this. Are you able to create a small GH repo that reproduce this issue so I can dig around it locally?

xzyfer · 2017-02-13T12:27:21Z

I suspect there's something about how you're using gulp + webpack + typescript that is causing an issue, and by going through the exercise of peeling back the layers you'll stumble upon it.

MLoughry · 2017-02-13T15:48:46Z

I'll try to get a minimum repo in the next few days.

…

________________________________ From: Michael Mifsud <[email protected]> Sent: Monday, February 13, 2017 4:26:14 AM To: sass/node-sass Cc: Michael Loughry; Author Subject: Re: [sass/node-sass] Error: Module did not self-register (#1895) I don't really know how to progress this. Are you able to create a small GH repo that reproduce this issue so I can dig around it locally? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsass%2Fnode-sass%2Fissues%2F1895%23issuecomment-279374702&data=02%7C01%7Cmiclo%40exchange.microsoft.com%7Cba3ece0a77694df51f3a08d4540b82e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636225855792346519&sdata=nWcrtKXl0kdhclgP1UWWTh711Sn0xtafovFb85F9hiI%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAT29qUa0jFIbjFQ63i1ey_IKka1cBHiTks5rcEvmgaJpZM4L-seP&data=02%7C01%7Cmiclo%40exchange.microsoft.com%7Cba3ece0a77694df51f3a08d4540b82e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636225855792346519&sdata=z7H331vlumhrBfU7awa4ecSVPTtmokDEzW%2BbiQDnBOg%3D&reserved=0>.

MLoughry · 2017-02-13T19:36:14Z

I have a minified repro that I'm working on cleaning up before I upload. However, one key finding is that the trigger for this bug is having two separate rules entries that trigger the sass-loader in webpack config. Eg.,

{
       ....

       module: {
            rules: [
                {
                    test: /\.scss$/,
                    exclude: /\.global\.scss$/,
                    use: [
                        '@microsoft/loader-load-themed-styles',
                        'css-loader?modules&minimize',
                        {
                            loader: 'postcss-loader',
                            options: postCssOptions
                        },
                        'sass-loader'
                    ]
                },
                {
                    test: /\.global\.scss$/,
                    use: ExtractTextPlugin.extract({
                        fallback: "style-loader",
                        use: [
                            'css-loader?minimize',
                            {
                                loader: 'postcss-loader',
                                options: postCssOptions
                            },
                            'sass-loader'
                        ]
                    })
                },
            ]
         }
}

If I comment out all imports of .global.scss, so only the .scss rule is executed, the issue goes away.

MLoughry · 2017-02-13T21:28:22Z

Managed to hack our project down to a fairly minimal repro: https://github.com/MLoughry/node-sass-issue-1895

MLoughry · 2017-02-13T22:13:04Z

As an additional data point: when I first implemented the global/component styles distinction in our project, I had originally tried to use gulp-sass for the global styles (and continue using sass-loader for component styles). I ran into this same error at the time, and simply worked around it by moving to the webpack (v1) config you see above. So the issue seems to be accessing node-sass through multiple entry points?

desaroger · 2017-02-14T09:17:07Z

Hi! I am stuck with the same issue. My case is a little different, I have two repos:

Repo A: It's a library related to render html. It uses node-sass ^4.5.0.
Repo B: It's our main repo, and uses Repo A for render some html and makes use of 'jstransformer-scss`, who needs node-sass ^4.0.0. In Repo B I require node-sass ^4.5

I have cloned the two repos, A and B. When I go to A and run tests works perfect (with mocha). If I go to B, works fine if I require A from the cloned folder (require('../repo-A')), but throws the error if I require it from node_modules (require('repo-A').

I tried (nothing worked, same results always):

rm -rd node_modules && npm i
npm rebuild
Change the versions of node-sass to 4.3.* or 4.1.*

Versions:

NPM version (npm -v): 3.10.10
Node version (node -v): v7.2.1
Node Process (node -p process.versions):

{ http_parser: '2.7.0',
  node: '7.2.1',
  v8: '5.4.500.44',
  uv: '1.10.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  modules: '51',
  openssl: '1.0.2j',
  icu: '58.1',
  unicode: '9.0',
  cldr: '30.0.2',
  tz: '2016g' }

Node Platform (node -p process.platform): linux
Node architecture (node -p process.arch): x64
node-sass version in repo A (node -p "require('node-sass').info"):

node-sass       4.5.0   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]

node-sass version in repo B (node -p "require('node-sass').info"):

node-sass       4.5.0   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]

npm node-sass versions in repo A (npm ls node-sass): [email protected]
npm node-sass versions in repo B (npm ls node-sass): [email protected]

Thank you!

MLoughry · 2017-02-17T00:23:50Z

Is there any progress on this, with or without my provided repro? Is there anything more I can provide to help the investigation?

xzyfer · 2017-02-22T10:39:27Z

Apologies I have missed the update on this issue. I'll take another look this weekend.

Termit1975 · 2017-03-24T19:52:19Z

I have the same issue here, any news

MLoughry · 2017-04-12T17:33:26Z

Ping. This is blocking my team's upgrade path to Webpack 2.0

Termit1975 · 2017-04-12T17:36:24Z

For info, we had the problem during initial configuration of Webpack 2 in our project, fixing the errors (there were so many), made the problem disappeared.

MLoughry · 2017-11-10T08:03:30Z

I've figured out that the issue that causes the re-entrancy is that the Windows drive letter casing can change between calls to binding, which in Node results in two separate instances of the module being created. In other words, two code paths might pass d:\github\node-sass-issue-1895\node_modules\node-sass\vendor\win32-x64-57\binding.node and D:\github\node-sass-issue-1895\node_modules\node-sass\vendor\win32-x64-57\binding.node, which Node treats as distinct paths.

I've verified a hack fix locally that normalizes the drive letter. I'll work on a proper PR to submit tomorrow.

…ackage Lower version of node-sass may failed to build in some machines (included travis ci): sass/node-sass#1895

HitalloExiled · 2017-12-05T17:14:25Z

Error persists in my environment even with the solution applied.

The first call was made with the path "f:\Projects\Surface\workbench\modules\source@surface\ compiler\node_modules\node-sass\vendor\win32-x64-59\binding.node".

What would be the impact of forcing the path case, since this call to binding seems to be encapsulated within the module?

Update

Debugging a little more. I have found that the problem may be related to other factors.

Forcing the path case at this point fixes my problem, but causes the webpack to raise the following alert:

WARNING in F:/Projects/Surface/workbench/modules/source/@surface/compiler/node_modules/css-loader/lib/css-base.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* F:\Projects\Surface\workbench\modules\source\@surface\compiler\node_modules\css-loader\lib\css-base.js
    Used by 1 module(s), i. e.
    F:\Projects\Surface\workbench\modules\source\@surface\compiler\node_modules\css-loader\index.js!F:\Projects\Surface\workbench\modules\source\@surface\compiler\node_modules\sass-loader\lib\loader.js!F:\Projects\Surface\workbench\modules\source\@surface\menu\index.scss
* f:\Projects\Surface\workbench\modules\source\@surface\compiler\node_modules\css-loader\lib\css-base.js
    Used by 1 module(s), i. e.
    f:\Projects\Surface\workbench\modules\source\@surface\compiler\node_modules\css-loader\index.js!f:\Projects\Surface\workbench\modules\source\@surface\compiler\node_modules\sass-loader\lib\loader.js!f:\Projects\Surface\workbench\client\source\app\index.scss

Now I suspect it is something related to the resolution of symbolic links in the webpack.

gbudge · 2018-08-05T03:56:13Z

This problem can also appear on Windows if you're using mklink to create symbolic links or junction points to share a single node_modules folder across multiple projects.

sass deleted a comment from guilhermevrs Nov 10, 2017

MLoughry mentioned this issue Nov 10, 2017

Use true-case-path to fix re-entrancy issue on Windows #2149

Merged

xzyfer closed this as completed in #2149 Nov 11, 2017

cjies added a commit to f2etw/f2etw.github.io that referenced this issue Nov 29, 2017

[package.json] Upgrade dependencies to latest, especially node-sass p…

d8e0132

…ackage Lower version of node-sass may failed to build in some machines (included travis ci): sass/node-sass#1895

MLoughry mentioned this issue Dec 5, 2017

Normalize drive letter #2179

Closed

This comment has been minimized.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error: Module did not self-register #1895

Error: Module did not self-register #1895

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017 via email

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017 via email

MLoughry commented Feb 13, 2017

MLoughry commented Feb 13, 2017

MLoughry commented Feb 13, 2017

desaroger commented Feb 14, 2017 •

edited

Loading

MLoughry commented Feb 17, 2017

xzyfer commented Feb 22, 2017

Termit1975 commented Mar 24, 2017

MLoughry commented Apr 12, 2017

Termit1975 commented Apr 12, 2017

MLoughry commented Nov 10, 2017

HitalloExiled commented Dec 5, 2017 •

edited

Loading

gbudge commented Aug 5, 2018

This comment has been minimized.

Error: Module did not self-register #1895

Error: Module did not self-register #1895

Comments

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017 via email

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017

xzyfer commented Feb 13, 2017

xzyfer commented Feb 13, 2017

MLoughry commented Feb 13, 2017 via email

MLoughry commented Feb 13, 2017

MLoughry commented Feb 13, 2017

MLoughry commented Feb 13, 2017

desaroger commented Feb 14, 2017 • edited Loading

MLoughry commented Feb 17, 2017

xzyfer commented Feb 22, 2017

Termit1975 commented Mar 24, 2017

MLoughry commented Apr 12, 2017

Termit1975 commented Apr 12, 2017

MLoughry commented Nov 10, 2017

HitalloExiled commented Dec 5, 2017 • edited Loading

Update

gbudge commented Aug 5, 2018

This comment has been minimized.

desaroger commented Feb 14, 2017 •

edited

Loading

HitalloExiled commented Dec 5, 2017 •

edited

Loading