I am trying to use Firebase admin SDK in my server. When I deploy I get the error I am missing file node-v59-linux-x64/grpc_node.node in firebase-admin node_module map. I added "grpc": "1.7.1" in my package, but I still do not get that file after NPM update. I get an older version, node-v57. I also checked this path https://registry.npmjs.org/grpc/-/grpc-1.7.1.tgz, but I could not locate the file. I deleted my node_modules map and ran npm install again, still no node-v59.
How/where can I download that file? Is there any one who can put the file here so I can manually add it?
Error: Cannot find module
'/data/app/node_modules/grpc/src/node/extension_binary/node-v59-linux-x64/grpc_node.node'
This kind of problem is usually caused by installing the library on one system, then deploying and running it on a different system that requires a different binary file.
The simplest solution to this problem is to run npm rebuild after deployment on the system you deployed on.
Alternatively, if npm rebuild is not an option, you can pre-install the binary for the system you are deploying on by running npm install with some extra options. The --target argument allows you to install for a different version of Node. An argument of --target=9.0.0 installs the binary for Node 9 (only the major version has to match). The --target_platform argument allows you to install for a specific operating system: windows, linux, or darwin (Mac). The --target_arch argument lets you install for a different processor architecture: ia32, x64, or arm. And finally, the --target_libc argument lets you select binaries built for a different libc: glibc or musl (for Alpine Linux).
So, in your case, you should be able to get that binary by running
npm install --target=9.0.0 --target_platform=linux --target_arch=x64
I had the same problem. You can download the file here: https://storage.googleapis.com/grpc-precompiled-binaries/node/grpc/v1.7.1/node-v59-linux-x64.tar.gz
This helped in my case, based on #murgatroid99’s answer:
npm rebuild --target=8.1.0 --target_platform=linux --target_arch=x64 --target_libc=glibc --update-binary
It downloads the required binary to your node_modules/grpc directory.
I run macOS X on my dev machine and I’m deploying to AWS Lambda; this keeps both runtime versions installed, which means I can develop and test locally and then deploy to Lambda.
Related
I am in a unique situation where I can run npm install only on a linux based machine even though I plan to run my electron/node application on an offline Windows machine.
So, is there a way to tell npm to perform an install and "trick" it to npm install the windows version of each module?
I understand most modules are based on javascript and are not native, but a few are dependent on operating system, such as electron itself.
Perhaps I could modify any header information npm sends out which tells the servers which operating system I am running?
So, is there a way to tell npm to perform an install and "trick" it to
npm install the windows version of each module?
No. If you want NPM to install for windows, then you have to run NPM on windows.
For pure Javascript modules, you could "probably" install for Linux and then just copy the directories over to windows, but you'd have to know that these were pure Javascript modules that contained no native code and did not use any binaries or compile any native code and copying directories behind the back of NPM is asking for it to be confused about what you have.
It sounds like perhaps you should explore fixing whatever issue is keeping you from running NPM on your windows box directly.
Is there a way to do an npm install that downloads dependencies but then it does not try to compile native addons?
Long story: My company has a build server running on Windows (can't change that) and it's getting complicated to compile some native addons there. This application is eventually deployed to Linux, so an npm rebuild is necessary anyways. Also, I can't do the npm install on the destination servers because they don't have access to the registry.
thanks
You can create a script (for Windows a JS file, for every other platform a shell script) that does nothing and is used instead of the normal node-gyp.
After that use
npm config set node_gyp <script_with_full_path>
to force npm to use your script instead of the normal node-gyp and by that skip the compile step.
Please note that requiring the module that used gyp may fail because the built file is now missing.
Hope this helps.
Is it possible to copy a set of NPM installed files and associated files from a Mac computer to a Windows computer, and for all those files to work?
For example, transfering Node.js files with some other NPM files from Mac to Windows, then running node app.js in that directory (on the Windows Command Prompt).
Thanks! :)
The binary, npm, that you install is platform dependent, as is node.js. That's why there are different releases for each platform available on the download site.
For the most part, your project files are platform independent. For example, most of your JavaScript files will all be used by node.js and work just fine without having to worry about what platform you are on because the system details will be dealt with by node.js itself.
However, some modules are platform dependent. For example, anything that uses node-gyp will try to compile on your platform whenever the module is installed by npm. You do not have to worry about that though because it is handled by npm, that's why you're using a package manager.
Copying node_modules can be done; but it's more often than not better and easier to just run npm i on whatever machine is going to be running your application. You can avoid having to worry about version problems using something like npm shrinkwrap which will lock down the version of a package that your module depends on.
NPM packages that contain native addons/dependencies are tied to the OS + NodeJS version and have to be rebuilt specifically for the system you intend to use them on. This is why you're seeing the error mentioning bson.node, it is a native addon that has to be rebuilt, this can be done with the npm rebuild command.
When I run "FullPathHere\npm.exe" -v on my dev machine I get 3.4.0.
When I copy that file to my build machine and run that (using the full path) I get 2.14.12.
Which is better than the installed version (which is 2.7.4), but not the V3 that I need.
Why is the same EXE not giving me the same version number?
What file are you actually copying? There is no such thing as npm.exe in the standard Node install for Windows. There is npm.cmd, which is a batch script that ultimately calls the npm CLI which runs inside of the Node engine.
So to answer your question, it seems to me like you are simply copying the batch script, which simply uses your environment variables to execute whatever installed version of NPM you have.
Turned out I needed to use npm to update npm.
Once I did that, it updated to the latest version.
I frequently hear from experienced node developers that checking in node_modules is good practice. But most developers write on Mac/Darwin x64, but deploy on Linux x64.
If a node module happens to be written in C, and I install it on OS X, wouldn't I have to rebuild it on Linux?
The answer is: it depends on the package
Most packages do require reinstall, as node gyp the compiler does not cross compile by default - thanks #tkone.
Some packages like node-sass dynamically download prebuilt binaries for the relevant platform (previously node-sass used to include binaries for all platforms, however this has changed recently).
The now current node-sass 3.4.2 doesn't include the binaries in the originally downloaded npm package (as found in the npm package cache under ~/.npm).
What it does is that its install.js script will download the platform specific binary and store it under vendor/{platform}-{arch}-{process.versions.module}.node. Once installed, the install.js script normally isn't invoked again by npm.
So when you check in node_modules, it will contain the binary only for your initial platform.
For the fun of it I moved away the downloaded binary, which should be the same as someone else checking out your node_modules on a different platform. When then run, node-sass is so smart to detect that the required binary doesn't exist. It exits gracefully, recommending to run npm rebuild node-sass (also hinting that this is usually necessary when you change the node version). This will download the binary for the current platform, and then all is fine.
However, that's totally specific to node-sass, other packages with binaries may behave entirely different.
(See Node.js release versions for an explanation of process.versions.modules aka. NODE_MODULES_VERSION that determines the last number in the binary download URL. The binary name is constructed in function getBinaryName() in ~/.npm/node-sass/{version}/package.tgz/lib/extension.js )