System information
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): macOS Ventura 13.2.1
TensorFlow.js installed from (npm or script link): npm
TensorFlow.js version: 4.2.0
Describe the problem
I had previously used the #tensorflow/tfjs-node library successfully with no issues. Now, however, I have changed environments and unfortunately I am running into issues. I don't have the original source code any more to compare to see what the difference is.
I am running under node v18.4.0, although I have tried v16.16.0 and v14.21.2 (using nvm on macOS).
The problem is now it seems the library wants all sorts of supporting modules, which are not installed:
aws-sdk
nock
mock-aws-s3
It will not build without these, so I npm i them and then it builds happily.
So first question: why might my environment now be needing these where it didn't need them before? What might be different? As I say, sadly I don't have the last environment around any more.
Having built this, I now receive the error:
Error: #package/learn package.json is not node-pre-gyp ready:
package.json must declare these properties:
binary
Although I could configure all this, I think it is the wrong thing to do, since I had it up and running previously without any of this. Is where are these issues now coming from?
Can I run the #tensorflow/tfjs-node without installing or needing those three dependencies? I can provide the other config if it is not apparent to someone who has had the same issue.
Related
I've recently migrated my project to Angular 13. It builds locally on my Mac, however it's started to fail when I run it in my Docker build container (tested both locally and on our CI/CD server.
It's complaining about the DeckGL import:
Cannot find module '#deck.gl/layers' or its corresponding type declarations.
1 import * as Layers from '#deck.gl/layers';
Cannot find module '#deck.gl/geo-layers' or its corresponding type declarations.
2 import * as GeoLayers from '#deck.gl/geo-layers';
Cannot find module '#deck.gl/aggregation-layers' or its corresponding type declarations.
3 import * as AggregationLayers from '#deck.gl/aggregation-layers';
I've used npm list to ensure the dependencies are the same on my Mac and within the Alpine container and have also tested using the same Node version (and have tried a couple of different Node / Apline images), however, the issue persists, whilst still working locally.
Any ideas what could be causing this?
Really silly issue, but posting an answer in case someone runs into a similar issue in future.
I had accidentally run npm install in a top-level directory, and had installed some Node modules that didn't end up in my package.json file. In my case, I had the core deck.gl module installed in my package.json, but none of the layer packages (which are separate npm modules).
When I was running it locally, it was finding the correct dependency, but when running it on the CI/CD environment, it was obviously failing.
I have written a Electron application using Node, Electron Boilerplate, and phantom. It works perfectly fine for me on my linux machine, I copied the source over to Windows 10, and ran with npm start, and all goes smoothly.
However, when I try to build the application with the boilerplate module using npm run release, things go a little less smoothly. I can install and open the application just fine, but when I click the button that activates the phantom module, the windows goes all white and nothing happens. I was able to logs some errors with the dev tools.
First, I have:
C:\...\dist\win-unpacked\resources\app.asar\node_modules\phantom\lib\phantom.js:361
Uncaught (in promise) Error: Error reading from stdin: Error: write EPIPE(…)
I did some research into similar issues, namely here, and it seems to me the issue is starting the child process, PhantomJS, with the npm module phantom. Originally, I was using a WPF application I wrote in C# to start the process, and that worked just fine. This leads me to believe that the phantom module is the culprit.
So I tried swapping out the npm phantom module for horseman, but got similar results:
Unhandled rejection HeadlessError: Phantom immediately exited with: 4294967295
at ChildProcess.immediateExit (C:\...\dist\win-unpacked\resources\app.asar\node_modules\node-horseman\node_modules\node-phantom-simple\node-phantom-simple.js:153:23)
at ChildProcess.g (events.js:286:16)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:204:12)
Here is a shot in the dark. I am not positive this will solve your issue but here it goes:
GYP and miss-matched binaries
Phantom and many other node modules use binaries built for the specific OS that it will be running on. Sometimes in your npm log files you will see references to node-gyp. Node-gyp simply helps to build native add-on's in node modules. When the binaries are built they are usually built against, among others, three main parameters, the operating system, cpu architecture and version of node that is doing the installation.
I think you need to rebuild phantomjs to the version of node Electron is using. Most of the time the node version you have installed on your machine and the node version running in Electron are not the same. Electron does its best to keep up, but there is always a little lag because of the amount of work and testing required to keep up-to-date.
When you install phantom by running npm install phantom it will assume it needs to install or build the binaries for the node version your machine is using. Then when your Electron app tries to run phantom it tries to call the binary of the Electron's node version. When it isn't there the child process immediately exits with an error.
How to fix
Luckily, there are other people out there that have figured out how to fix this issue and have created a great tool to help generate the correct binaries.
Enter electron-rebuild:
https://github.com/electron/electron-rebuild
Electron-rebuild can be run in the command line, and it will rebuild all of your native modules to the version of Electron your project is using.
To install:
npm install electron-prebuilt
To use (in Windows):
.\node_modules\.bin\electron-rebuild.cmd
This should be enough to put the correct binaries in the right place.
Other thoughts
Sometimes you can use a package that uses a dependency called node-pre-gyp. E.g. sqlite3. There is a known issue I ended up running into when trying to rebuild my packages for Electron. Basically, in order to avoid this issue (if you run into it) just append --pre-gyp-fix to the above command.
Tangent for those who run into the pre-gyp-fix issue
One more thing on the pre-gyp-fix: If one or more of your dependencies depends on one of the modules that need the pre-gyp-fix then they will be looking for the binary in the wrong place even if they are running in Electron. All of the pre-gyp binaries are stored in a folder similar to this:
.\node_modules\sqlite3\lib\binding
In my current project I have three folders here, one for Electron-v1.4, and two for node-v46 and node-v50. (hack alert) In order to have sqlite3 work with my other dependencies I copy the binary found in the Electron-v1.4 folder and put it in both node-v* folders. That way when running in Electron, all dependencies are running the correct binaries even though they are looking for them in the wrong place. (end hack alert)
Conclusion
There is no way I can be sure this has anything to do with the issue you are seeing. But it is worth a shot to see if it fixes your problem. If not then at least I hope I can help someone else experiencing the same issues I ran into.
Today I was trying to work on Angular2 (template https://akveo.github.io). As per installation guide, I ran following commands.
I have installed Node.js v6.9.1.
npm install --Worked fine.
npm server --Failed with below error.
E:\........\node_modules\script-ext-html-webpack-plugin\index.js:3
const INLINE = 'inline';
^^^^^
SyntaxError: Use of const in strict mode.
at exports.runInThisContext (vm.js:73:16)
at Module._compile (module.js:443:25)
After many random searches and failing to resolve it, I decided to think about it with a calm head. To me it looks like it is a problem with ES2015/ES6. Package script-ext-html-webpack-plugin uses const variable which is a ES2016 feature. However system is unable to resolve it.
Also this problem can come with any package like hapi, selinium etc. But everything should have same solution I guess.
I have tried many related commands on the installation guide of the website mentioned above but nothing works and ends with same error. I have also many have faced same issue online but nothing concrete is visible as answer.
Could anyone help me out?
Update
Below approach has also fixed many of my colleague's machine who were facing some random errors with nodejs.
This problem is resolved in at least my machine. I am certainly not a person who understand nodejs completely but got it working after some googling. The solution given below may be common to many other issues I guess.
The system I am working has Windows 10 as Operating System and has 64 bit processor.
Go to control panel and uninstall nodejs (just to make sure you do not have traces of any previous install).
Install latest version of nodejs from their website (I installed v6.9.1 for 64 bit processor).
Go to Environment variables for system (just type environmental variables in start menu if using Windows 10) and edit the Path. Delete ‘C:/Program Files (x86)/nodejs’ (as I had installed 64 bit nodejs). This ensures when using command you do not use any other previously installed nodejs.
Start command prompt in Admin mode and navigate to your project and run npm install.
In case you get any/some error, then run npm info graceful-fs -v or npm info graceful-fs whichever runs in your machine.
Then run npm update -g npm.
Then run npm install again and this time it should work.
Run npm start and everything should work fine.
On running website, sometimes we see any other issue and that can be seen from console logs. But good thing is, console logs also tell you the problem. In most cases its related to 32 bit and 64 bit processor due to our recent changes. In my case, I was facing issue with SASS configuration due to 32/64 bit machine and console log asked me to run npm rebuild node-sass to fix the issue.
Go back to command prompt, hit Ctrl+C to stop npm server. Run node rebuild node-sass. Run npm start again and everything should be working.
Hope it helps.
I've seen similar questions but no real solution that worked for me yet (most users just reinstall fibers or meteor (I'm not using meteor)).
I've added the nodejs module Sync to my nodejs 0.12.6 project. It's dependency is the Fibers module that got installed automatically with Sync. Now I wanted to load Sync via require, but it fails with the message
... /win32-x64-v8-4.3/fibers.node not found
And it's correct: In sync/node_modules/fibers/bin/ is no directory named win32-x64-v8-4.3, only win32-x64-v8-4.2 and renaming didn't solve the problem (would have been too easy)... 🙈
How can I solve this problem? How can this happen?
What is the meaning of the last number (4.3)? I guess it's windows, 64bit, Javascript v8 engine, and then? Fibers version?
Any ideas or hints?
Update:
I tried to updgrade node to 0.12.6, but nothing changed.
I found out what the 4.3 is about, it's the v8 version. Well, when running my application with electron, it is v8: '4.3.61.21'. When checking the version with node, it is 3.28. So it's maybe electrons "fault"?
Update #2:
Okay i found out that electron is based on io.js and not node. That explains the different v8 versions. But still no solution. When installing fibers with latest io.js (2.3.3), it tests the 4.2 binary, but electron requires 4.3 :(
Update #3:
Even with the same io.js version 2.3.1 as electron, it does only install the 4.2 binary.
Update #4:
Now, I've tried all three ways described at http://electron.atom.io/docs/v0.27.0/tutorial/using-native-node-modules/ (with electron version 0.29.1) - still no solution. There aren't any binaries for v8-4.3, still only the v8-4.2 ones. :(
Solution:
See my answer below. :)
At the end, i had to compile fibers on my own. As described in Update #4, i've tried it before. But node-gyp always failed and i didn't notice that i have to link to the new binary file on my own...
cd ~/my-project-root/
npm install sync
cd ./node_modules/sync/node_modules/fibers
node-gyp configure
HOME=~/.electron-gyp node-gyp rebuild --target=0.29.1 --arch=x64 --dist-url=https://atom.io/download/atom-shell
Then i've created the missing directory and moved the new binary there:
mkdir bin/win32-x64-v8-4.3
mv build/Release/fibers.node bin/win32-x64-v8-4.3/fibers.node
Now Sync works like a charm.
You need to use the electron-rebuild tool to rebuild your native module against the version of Electron you're using
Full error/warning log: http://pastebin.com/xNjC4FDr
I had problem as well when I tried to install MongoDB, I have made SO question of it but, that was only warnings, so I could ignore it. But this time it's not only warnings, but also red error.
What do I have to do? Is my Nodejs messed up because I've installed Visual Studio Tools for NodeJS in the past? Or is this normal behavior? What can I do about this, I prefer not to see errors/warnings when I install something on NPM.
The problem is that hiredis does not support Windows currently. The link to the Windows-compatible fork in the hiredis readme seems to be outdated (last commit in 8/2013 as of this writing), so you may be out of luck.
However hiredis is not required by the redis module, it's an optional dependency that just makes parsing the redis protocol faster than the pure JavaScript parser that is bundled with redis. You may see a similar thing with other modules that have optional dependencies like this. Typically if you see the module tree outline at the end of the console output, that means the module installation was successful.