I am trying to scrape dynamic content in Node webkit by using Phantom .
I have added phantomjs to env variable also.
When i run the application i get a version mismatch error:
"Uncaught Error: Module version mismatch. Expected 43, got 46."
By running nw:version i get the following versions:
nw.js v0.12.3
io.js v1.2.0
Chromium 41.0.2272.76
How should i get around this error?
If you were able to implement similar functionality using some other package, let me know.
Native modules (phantom is one of them, my experience was with lwip) must be rebuilt to work inside nw.js; the ones you install with npm are not compatible. It is also recommended to install node.js version matching that which is used by nw.js (i.e. io.js 1.2.0).
The instruction on how to rebuild: https://github.com/nwjs/nw.js/wiki/build-native-modules-with-nw-gyp
Basically, you would
$ npm install -g nw-gyp
$ cd node_modules/phantom
$ nw-gyp configure --target=0.12.3
$ nw-gyp build
Note "0.12.3" version in configure because that's what your nw:version shows.
Also, note different pre-requisites depending on which OS you use: https://github.com/nwjs/nw-gyp
To do web-scraping in nw.js I successfully use the following stack (on Windows 7):
nw.js 0.12.3
phantomjs module with phantomjs 1.9.8 or 2.0.1b
node-phantom-simple module
Related
My code runs MacOS, Windows 10 and Ubuntu. However when I run it on Raspbian, I get the error
Encountered error: Error: #grpc/grpc-js only works on Node ^8.13.0 || >=10.10.0
(node:18099) ExperimentalWarning: The http2 module is an experimental API.
my versions are:
pi#raspberrypi:~ $ node -v
v13.1.0
pi#raspberrypi:~ $ npm -v
6.12.1
The problem occurs when I set the snapshot for a firebase focument. Thank you guys in advance...
If you trying to run an electron js based app on device which has cpu with arm architecture you have to use either electron#3.0.13 or electron#5.0.0 . In addition, if are you going to use another library which uses grpc , use electron#5.0.0 . Otherwise you will drown in errors. Just delete the version of electron in packege.json file. Make that line as electron: "5.0.0" and delete node_modules with package-lock.json file. After npm install you are good to go.
I have developed a node API for my angular application, My node application uses node-printer package for printing pdf files generated by node, when i tried to run my application using nodemon i am getting an error
node printer.node is not a valid win32 application
The same application is working on the other machine without any error. both the machines are of X64 bit architecture.
also i have also tried to install node js 32 bit then too i am getting same error.
This worked for me, installing printer as such:
npm install printer --build-from-source
After so many attempts i have deleted node_modules folder from an application and fire an npm install command to add all modules again that resolves the problem.
Hi there let me go through what's happened on my site here in 2022.
So if you're going to use npm install printer for your Electron application, you're using a native module as deemed by electron.
Since Electron has a different application binary interface (ABI) from a given Node.js binary that you used to install your printer . Therefore, we need to rebuild the native module (in this case printer) for Electron.
For more detail check this out.
First, install electron-rebuild for your project. npm i electron-rebuild.
Second, install a native module using e.g. npm i printer
Third, after installed native module, execute ./node_modules/.bin/electron-rebuild to rebuild the native module.
I tried https://github.com/zeit/micro
and unable to run npm start
I run micro in terminal and also see the error
I type in terminal "micro"
Response :
/usr/local/lib/node_modules/micro/bin/micro.js:33
let file = args.sub[0]
SyntaxError: Block-scoped declarations ...
The error message looks as if you were using a version of Node.js that is not up-to-date. So, update your installation of Node.js, and everything should be fine.
Just in case you don't do that yet, have a look at the Node Version Manager which makes installing and managing different versions of Node.js a breeze. If you have installed it on your local system, installing the current version of Node.js becomes as easy as:
$ nvm install 7.5.0
(Or whatever the current version of Node.js is when you read this answer.)
I am trying to run node-serialport in nw.js. After following the nw.js documentation concerning native modules, node-serialport seems to build just fine, and runs perfectly in a regular node process.
Unfortunately, I get the following error in the nw.js console window:
{project_dir}\node_modules\serialport\node_modules\bindings\bindings.js:83 Uncaught Error: Module version mismatch. Expected 48, got 46.
How can I run these together? Am I missing something obvious?
Note that I'm currently running:
Windows 7 x64
Node v4.4.4
npm v2.4.1
nw.js v0.15.0
node-gyp v3.3.1
serialport v3.1.2
Apparently I needed to update to the Current version of Node (v6.2.0) instead of the LTS version (v4.4.4). After updating and rebuilding serialport, everything works perfectly!
I have a node webkit application that uses the mdns module for publishing a Bonjour service from a Mac (with Mavericks). When I run the server code with node server.js everything works OK, but when running the node webkit application that uses the same server code I get this error:
"Uncaught Error: dlopen(/Users/me/myfolder/node_modules/mdns/build/Release/dns_sd_bindings.node, 1): no suitable image found. Did find:
/Users/me/myfolder/node_modules/mdns/build/Release/dns_sd_bindings.node: mach-o, but wrong architecture", source: /Users/me/myfolder/node_modules/mdns/lib/dns_sd.js (35)
Apparently when you install the mdns module with npm it's built for an x86 architecture and I need it for i386, because node-webkit is built for i386 (I found out about this by reading this thread: http://forums.macrumors.com/showthread.php?t=879780). You can verify it by running this in a terminal:
$ lipo -info /Applications/node-webkit.app/Contents/MacOS/node-webkit
Non-fat file: /Applications/node-webkit.app/Contents/MacOS/node-webkit is architecture: i386
I found this link suggesting a solution: https://github.com/rogerwang/node-webkit/issues/296 for another module (node proxy). The suggested instructions are:
I managed to build a 32-bit version of node-proxy as follows:
I installed nw-gyp
I ran nw-gyp configure --target=0.3.6
I edited the generated file nodeproxy.target.mk in the build directory by replacing -arch x86_64by -arch i386
I ran nw-gyp build
But as I'm not used to building node modules manually, while following the instructions it wasn't clear to me in which folder I should run those steps (I assumed it's in the module folder inside node_modules:
a) when I install nw-gyp I don't get the nw-gyp command to use globally (I guess the -g option is missing in the instructions)
b) using instead gyp configure --target=0.3.6 gives me an error saying that there is no option target
c) I tried skipping the configure step (just to try) and the build command breaks with:
Could not automatically locate src directory. This isa temporary
Chromium feature that will be removed. Use--depth as a workaround.
But when trying to use --depth (of course) it requires an argument, I couldn't find out what to put there.
So... how should I build the mdns module for using it with node webkit? (either the 0.8.6 version or the 0.10.0, I can adapt).
I managed to make it work.
As I had already installed the mdns module, I already had the source code of the module in the folder node_modules/mdns inside my project folder.
So these are the steps I followed to build the mdns module for the i386 architecture:
1) Install nw-gyp by running: npm install -g nw-gyp
2) Enter in the node_modules/mdns folder of your node-webkit project
3) Run nw-gyp configure --target=0.8.6 (this target is the version of the node-webkit you have installed)
4) And finally run nw-gyp build
I got a lot of warnings of deprecated functions, but it was built OK and now my node-webkit application can publish the Bonjour service successfully.
Unfortunately this is not the best solution, though, because the next person that installs the project will have to do the same after the regular npm install... But at least it's something to get it working.