Error: The specified module could not be found - node.js

I'm trying to use edge.js to execute some .NET code to print on windows in an Electron app. I've tried electron-edge and I've also tried manually building the edge.js modules targeting Electron following the instructions in the Electron docs, but I keep getting the following error when I try to use edge in the packaged app:
Error: The specified module could not be found.
\\?\C:\path\to\app\app-1.0.0\resources\app.asar.unpacked\node_modules\edge\lib\native\win32\x64\6.5.0\edge_nativeclr.node
at Error (native)
at process.module.(anonymous function) (ELECTRON_ASAR.js:178:20)
at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:178:20)
at Object.Module._extensions..node (module.js:583:18)
at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:192:18)
at Module.load (module.js:473:32)
at tryModuleLoad (module.js:432:12)
at Function.Module._load (module.js:424:3)
at Module.require (module.js:483:17)
at require (internal/module.js:20:19)
I've checked the filesystem and the edge_nativeclr.node module does, in fact, exist. My suspicion is that I'm somehow not building the module correctly and it's perhaps targeting the wrong version of node still and so electron is unable to import the module.
I tried several different things, including following electron-edge's steps to manually update the build.bat and add the --target=1.4.12 --dist-url=https://atom.io/download/atom-shell flags to the node-gyp configure build.
I also set the following npm config options in my .npmrc:
target=1.4.12
arch=x64
target_arch=x64
disturl=https://atom.io/download/electron
runtime=electron
build_from_source=true
msvs_version=2015
And ran the build.bat, making sure to set the EDGE_NATIVE environment variable to point to the generated edge_nativeclr.node file, but got the same result.

I finally got this figured out after banging my head against the keyboard for a couple days. I got some hints from electron-userland/electron-packager#217 and electron/electron#892, which pointed out that this error, "The specified module could not be found," could occur when the native module is missing a dependency, such as a .dll, and that you could use Dependency Walker to check the dependencies of any given .node module.
I loaded edge_nativeclr.node in Dependency Walker and noticed that VCRUNTIME140.DLL, the Visual Studio 2015 C runtime, was missing. Edge.js comes with the msvcr120.dll, the Visual Studio 2013 C runtime, but I'd been rebuilding the module with the msvs_version set to 2015.
Once I placed a copy of the vcruntime140.dll in the same directory as edge_nativeclr.node, everything started working as expected.

I also got this error even though I did have VC++ Redistributable x64 installed correctly. It turns out the error in my case was not actually a problem since everything worked fine (I was able to run the electron-quick-start app with electron-edge).
Even so, the author has fixed the install so that the error does not occur. https://github.com/kexplo/electron-edge/issues/25#issuecomment-272908409
Aside note, if you load edge_nativeclr.node in Dependency Walker, you will see the VCRUNTIME140.DLL resolved properly (e.g. under C:\Windows\System32 on my PC). However, you may see several question marks and errors. It turns out these are just due to some limitations in Dependency Walker and not an actual issue. See Dependency Walker: missing dlls

Related

npm run gulp primordials not defined

I'm trying to run npm run gulp and I'm coming up with this primordials is not defined error (I have also added the npm-shrinkwrap.json file as suggested which gets updated after running npm install but it doesn't fix my primordials is not define error):
> gulp-tutorial#1.0.0 gulp
> gulp
fs.js:47
} = primordials;
^
ReferenceError: primordials is not defined
at fs.js:47:5
at req_ (/Applications/MAMP/htdocs/wordpress/wp-content/themes/theming-main/node_modules/natives/index.js:143:24)
at Object.req [as require] (/Applications/MAMP/htdocs/wordpress/wp-content/themes/theming-main/node_modules/natives/index.js:55:10)
at Object.<anonymous> (/Applications/MAMP/htdocs/wordpress/wp-content/themes/theming-main/node_modules/vinyl-fs/node_modules/graceful-fs/fs.js:1:37)
at Module._compile (node:internal/modules/cjs/loader:1095:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1147:10)
at Module.load (node:internal/modules/cjs/loader:975:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:999:19)
at require (node:internal/modules/cjs/helpers:102:18)
Node.js v17.0.1
Any suggestions 🙌 ?
Primordials are used by Node.js internal modules and are not accessible to end user scripts. (That's their entire point for existing. Otherwise, you could modify Object.prototype and end up affecting Node.js internals, causing weird crashes and things like that.)
The module that is giving you this error is the natives module. The page for the package says:
This module relies on Node.js's internals and will break at some point. Do not use it, and update to graceful-fs#4.x.
Sounds like it's at that point where it's broken. Use npm ls natives to find out what's using it. (You might need to be in the /Applications/MAMP/htdocs/wordpress/wp-content/themes/theming-main directory when you run the command.) From there, you can try to figure out how to get rid of it.
Another possibility would be to try downgrading to an earlier version of Node.js to see if it works with that version.
The problem was with the versions not matching up. I also had 2 NodeJS installation paths and that was throwing things off.
I uninstalled them all, started from the beginning and used brew to reinstall.
Then checked that the versions were all compatible.
I also had to install node-sass and referred to this compatibility table to get the correct version - https://github.com/sass/node-sass#node-version-support-policy
Now its working and I can get on developing :) As of today Im running Node v17.0.1 Npm v8.1.0 Gulp cli v2.3.0

Using nodejs bindings to run native c++ code produces an error

I'm trying to develop an electron app, and I would like to use an npm package that gives vibrancy to a window. This is the package I'm trying to use: https://github.com/sebascontre/windows10-fluently-vibrancy
It uses a visual c++ code to call native windows methods to achieve this vibrancy effect.
I've cloned and I've run the npm install and build as described in the readme and ran the following:
npm install
npm run conf
npm run rebuild
All built successfully and I also see the build\debug artifacts of the c++ build.
When I try to run it (as described in readme):
cd spec\app
electron .
I'm getting the following error message:
Uncaught Exception:
Error: The specified module could not be found.
\\?\F:\Development\windows10-fluently-vibrancy\build\Debug\Vibrancy.node
at process.func [as dlopen] (electron/js2c/asar.js:155:31)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:857:18)
at Object.func [as .node] (electron/js2c/asar.js:155:31)
at Module.load (internal/modules/cjs/loader.js:677:32)
at tryModuleLoad (internal/modules/cjs/loader.js:609:12)
at Function.Module._load (internal/modules/cjs/loader.js:601:3)
at Module.require (internal/modules/cjs/loader.js:715:19)
at require (internal/modules/cjs/helpers.js:14:16)
at bindings (F:\Development\windows10-fluently-vibrancy\node_modules\bindings\bindings.js:112:48)
at Object.<anonymous> (F:\Development\windows10-fluently-vibrancy\index.js:1:35)
According to the message it cannot find the Vibrancy.node file - But I've verified that it exists in the specified location.
Any ideas how to make it run? I have cloned the package to test it since when trying to use the npm itself in my project it gave the same error so I figured I would try the source.
Today I had the exact same issue you're describing here.
I got it to work using electron-rebuild.
From the root of your project run the command: electron-rebuild
Hope this helps you, if not, maybe someone else.

NodeJS Debugging Error: No such module: http_parser

I was debugging my nodejs app in vs-code without errors, but suddenly it did begin to give this error:
Error: No such module: http_parser
at internalBinding (internal/bootstrap/loaders.js:104:17)
at _http_client.js:27:24
at NativeModule.compile (internal/bootstrap/loaders.js:363:7)
at NativeModule.require (internal/bootstrap/loaders.js:174:18)
at http.js:25:27
at NativeModule.compile (internal/bootstrap/loaders.js:363:7)
at Function.NativeModule.require (internal/bootstrap/loaders.js:174:18)
at Function.Module._load (internal/modules/cjs/loader.js:517:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
Actually the app works successfully, for example, express-js http functions work as expected, but i am unable to do debugging.
I have already installed that package, named as http-parser
Edit: Node Version: v10.14.2, there is no extensions installed, just the vs-code built-in debugging runtime. After i have inspected more, the execution was coming to the loader.js and was terminating afterwards.
Edit2: Renaming the project folder fixed the issue but why? Could anybody explain this?
What version of node.js and vs code are you debugging?
Some Solutions:
1.Try to rename the project folder
2.Disable extensions and see which extension is influencing the debugging
3.You could also disable the check boxes
All Exceptions and Uncaught Exceptions under Debug > Breakpoints, can debug your application
check if it works
Go to the debugger tab, go the Breakpoints section, and disable "All Exceptions" and "Uncaught Exceptions"
Deleting .vscode folder in working directory will help but if your debugging points are not getting enabled then try updating vscode. This happened with me when I was using latest nodejs version but a moderately old version of vscode.

Electron running SQLlite 3 on Windows - A dynamic link library (DLL) initialization routine failed

This is similar to this Electron Uncaught Error: A dynamic link library (DLL) initialization routine failed
ELECTRON_ASAR.js:173
return old.apply(this, arguments)
^
Error: A dynamic link library (DLL) initialization routine failed.
\\?\C:\workspace\client\client\desktop\node_modules\sqlite3\lib\binding\node-v57
-win32-x64\node_sqlite3.node
at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:173:20)
at Object.Module._extensions..node (module.js:671:18)
at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:173:20)
at Module.load (module.js:561:32)
at tryModuleLoad (module.js:504:12)
at Function.Module._load (module.js:496:3)
at Module.require (module.js:586:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (C:\workspace\client\client\desktop\node_modules\sqlit
e3\lib\sqlite3.js:4:15)
at Object.<anonymous> (C:\workspace\client\client\desktop\node_modules\sqlit
e3\lib\sqlite3.js:190:3)
I've tried everything suggested in this post and anything else I can find
I've installed electron-rebuild and added "rebuild": "electron-rebuild -f -w sqlite3 -V 1.7"
This is running without errors.
I tried "postinstall": "install-app-deps",
This isn't helping..
Anything else to try?
The files are in there..
The
This ended up being a mashup of a bunch of different issues on my end. I'll start with the simplest and go from there.
Platform
Your error there indicates that it wants node-v57-win32-x64, but if you are running from Electron it should be electron-v2.0-win32-x64 (or electron-v1.7-win32-x64 if you are using an older version). I ran into this as well because I am running sqlite3 in a child process. Child processes in Electron are in a full node context and not an Electron (browser or node+browser) context. I fixed this by passing the Electron version from the main browser process (process.versions.electron) to the child process via an environment variable and setting it on process.versions.electron in the child process.
WARNING: that is a HACK and works because I'm not using anything that expects a full Electron environment in that process. It is literally only to make it find the correct native bindings. A more correct fix would be to look into making electron-builder build node-v57-win32-x64 instead.
Speaking of which, let's create those next.
postinstall
"scripts": {
...
"postinstall": "electron-builder install-app-deps"
}
This should attempt to rebuild your native dependencies when running npm install or yarn install. If you have a project/app directory, they will be placed in project/app/node_modules/. Otherwise they'll go in project/node_modules.
Transitive Dependency
In my case, sqlite3 is actually a transitive dependency of another package in my dependency set. While electron-builder on Linux/OS X picked these up correctly and showed this during installer creation:
• rebuilding native production dependencies platform=linux arch=x64
• rebuilding native dependency name=sqlite3
the Windows build showed:
• no native production dependencies
This was fixed by adding the transitive dependency as a direct dependency. After I did this, the package started to be picked up by electron-builder for compilation and was spitting out errors.
Windows Build
To fix those errors:
Install python (I used the latest 2.7)
Install Microsoft Build Tools 2013 and restart
run your postinstall script again
This is the point where I said it was "half-solved" on my end. This should be the full solution for basic electron project setups.
yarn workspaces
I use the yarn workspaces feature and my project setup is something like this:
yarn-workspace-project/
workspace/
project/
web-app/
project-electron/
app/
For this kind of setup, yarn install is generally run in the yarn-workspace-project or yarn-workspace-project/workspace directory, rather than in each project. This produces a hoisted node_modules/ directory at yarn-workspace-project/node_modules. When creating the packaged version, electron-builder grabs the dependencies from that hoisted location and everything runs.
When running my start script in project-electron, however, electron . had some issues finding the native binding. The package using sqlite3 was installed under yarn-workspace-project/node_modules, and was therefore resolving sqlite3 to yarn-workspace-project/node_modules/sqlite3. This definitely exists per the yarn install, but the electron bindings got put in yarn-workspace-project/workspace/project-electron/app/node_modules/sqlite3.
There are multiple obvious solutions to that, so I'll leave that as an exercise to the reader. The key problem here is that the default bindings that get downloaded (I think? I don't recall them being built) for node-v57-win32-x64 do not work out of the box for Windows 10 like they do for Linux / OS X, even though the error indicates that they don't exist (which they do).

Installing node-sass on IBM i (formerly iSeries/ AS/400)

Has anyone been able to successfully install node-sass on IBM i?
I'm currently running Node 6.9.1, and am able to install many npm packages. However, the #angular/cli has a dependency on node-sass, and apparently, node-sass has a compiled component that is giving me grief to install.
My first issue had to do with being able to download the binary itself - because of our network setup, the IBM i was unable to download the binary from:
https://github.com/sass/node-sass/releases/download/v4.5.2/aix-ppc-48_binding.node
I was getting a timeout error. I was able to resolve that by changing the SASS_BINARY_SITE to the non-https version:
export SASS_BINARY_SITE='http://github.com/sass/node-sass/releases/download'
However, now, even though the binary downloads successfully, i get the following error when npm tries to test the binary:
Testing binary Binary has a problem: Error: Could not load module
/QOpenSys/QIBM/ProdData/OPS/Node6/lib/node_modules/node-sass/vendor/aix-ppc-48/binding.node.
The module has an invalid magic number.
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 (/QOpenSys/QIBM/ProdData/OPS/Node6/lib/node_modules/node-sass/lib/binding.js:19:10)
at Object.<anonymous> (/QOpenSys/QIBM/ProdData/OPS/Node6/lib/node_modules/node-sass/lib/index.js:14:35)
And then npm tries to build the binary locally, but fails because Python2 isn't available on this machine. I can request the installation of Python2, which is a long process in our environment, but before i continue down that rabbit hole, I'd like to know if it's actually possible to have node-sass working, and if so, is there another binary that i can point the npm install at to use instead.
Or, is there an alternative means of get node-sass working?
As of 2017 this will likely not be possible. In addition to Python you will need the entire cpp toolchain to build node and node addons. Since this is already a very hard requirement for desktop PCs, systems like that will have a even harder time. Judging from their binding.gyp, there is just support for OS X, Windows and Linux.
node-sass is known to be hard to build also across the node use base.
Very likely you rather want to have a build / CI step on Linux that compiles your SASS files and builds your artefact.

Resources