I am using nodejs/express to develop a simple RESTful API.
Yesterday I could make calls to the fs.access method (used to check the existence of a file/folder). I can't today. Even if I use the REPL on the terminal it says fs.access is undefined. This is the output:
> var fs = require('fs');
undefined
> fs.access
undefined
> fs.exists
[Function]
nodejs --version gives me this version, which is the latest available from Ubuntu's repositories: v0.10.25
I know there is the fs.exists method, but as per documentation it has been deprecated.
How can I solve?
Thank you,
Umar
Node.js version 0.10.25 is not the latest and according to it's documentation a function named access is indeed not present in the file system api.
According to the official website, the latest LTS version is 4.2.6 and the latest stable one is 5.5.0. I've just checked and everything works as excepted on my computer using a recent version of Node.js.
If you're having trouble installing a more recent version of Node through your distribution's channels, you might want to consider using a third party package manager like Linuxbrew that installs stuff into your home directory, independent of the OS you're using.
Related
I'm trying to deploy a node.js app but get stuck with an error about missing dependencies for gdal.
Error: /lib64/libm.so.6: version 'GLIBC_2.27' not found (required by /var/app/current/node_modules/gdal/lib/binding/gdal.node)
How would I go about installing this required dependency?
gdal-async on npm explicitly supports AWS.
As its author, I will be happy to help you if it doesn't work - you can create an issue on github.
I don't know what you call gdal.js.
There is the original gdal by Mapbox and Natural Atlas that is not actively developed anymore.
There is gdal-next on which I used to work a little bit which has a current version of GDAL but it is not very active either.
There is my gdal-async which is the only one that is currently active.
And there is an Emscripten port that is pure JS and runs in the browser, but it is stalled at GDAL 2.
Supporting AWS is simply a matter of compiling with the right libraries.
I get this message when I start a local Firebase server with firebase serve:
Warning: You're using Node.js v8.9.4 but Google Cloud Functions only supports v6.11.5.
But there is no info about what to do. What do I need to do to downgrade Node.js to v6.11.5? Should I use that version just for Firebase projects and the latest released version of Node.js for other projects? In that case how to I do that?
EDIT: The warning now looks like this and I am unable to run a new nearly empty project:
Warning: You're using Node.js v8.9.4 but Google Cloud Functions only supports v6.11.5.
! functions: Failed to load functions source code. Ensure that you have the latest SDK by running npm i --save firebase-functions inside the functions directory.
! functions: Error from emulator. mod.hasOwnProperty is not a function
So I really think I have to downgrande Node.js. But I do not know how to safely do that. Hm, looking at http://nodejs.org/ I can't even find version v6.11.5?
EDIT 2: Just checked in the new project if npm update --dev fixed the problem. It did not. (Actually no packages where updated.)
That's just a warning. You can ignore it if you know what you're doing. It's telling you that your local emulation of a function (running on node 8.9.4) may not perfectly match what the function will do when it's deployed to Cloud Functions (running 6.11.5). But as long as you're not using any features of node that are not available on node 6.11.5, you won't have a problem. I use newer versions of node to test locally all the time without problems.
You can uninstall and reinstall Cloud Functions emulator and Firebase Tools using the commands provided in the GitHub Troubleshooting guide. Since you are using Firebase, follow the instruction for the ‘Firebase Tools’.
Node v8 is now available for cloud functions:
https://firebase.googleblog.com/2018/08/cloud-functions-for-firebase-config-node-8-timeout-memory-region.html
So I believe this warning can truly be ignored...
There are several tools listed in the answers to this question
For Windows I just used nvmw successfully to accomplish this same task.
You will get the nvm here
After installation of nvm.
just use this command
"nvm install 8.9.1 64bit" you can use any version here or 64bit 32bit according to your system config
after that installation use
"nvm use 8.9.1"
Well here's an odd situation I've found. I've been using PHP and MongoDB together on a project, and updated the associated software. After the upgrade, I did make sure to update the new conf files and all is well --- except when I try to use the MongoClient class, I get the following fatal error:
Fatal error: Uncaught Error: Class 'MongoClient' not found in /srv/http/test.php
So my first instinct was to check my /etc/php/php.ini to make sure that mongodb.so was correctly included. I found it after the other extension lines:
extension=mcrypt.so
extension=zip.so
extension=mongodb.so ; <--- here it is
With that checked, I loaded up a quick phpinfo() script to check that I was using the right php.ini file, and confirmed that I am. And not only that, the mongodb driver also appears to be loaded correctly!
Loaded Configuration File /etc/php/php.ini
. . .
mongodb support enabled
mongodb version 1.1.1
mongodb stability stable
libmongoc version 1.3.1-dev
libbson version 1.3.0
So I restarted httpd and tried again. No dice, still can't find the MongoClient class. So I tried to install it from pecl instead of my distribution's package manager, and the situation is the same as described above.
So here's a quick rundown of the situation:
Linux kernel 4.3.3
PHP Version 7.0.1
php-mongodb version 1.1.1
Yes, 1.1.1 supports php7.
Seems properly configured, and mongodb is enabled and shown in phpinfo().
Tried installing the mongodb driver through pecl and my distro's package manager.
Other info that may be useful:
MongoDB Version 3.2.0
mongod is running
Also tried rebooting, no change.
Well I found the answer.
The class has been changed. It's no longer \MongoClient, and is now \MongoDB\Driver\Manager
All that I need is a refactor. The new driver is designed to be a lower-level driver for high-level functionality to be filled with userspace libraries, so anyone else upgrading to php7, make sure you check that you'll be comfortable with the new driver, or that the userspace libraries exist when you do it. Hopefully this question/answer helps others in the future.
Commenter ianaz below has posted this good userspace library for MongoDB: http://mongodb.github.io/mongo-php-library/
I'll be attending a MS course tomorrow and I'm supposed to install NodeJs version 0.12.7. However, when I follow the link provided, I only get a directory listing of a bunch of files. And I'm certainly not sure which one(s) I need (I'm on Win 8).
I also tried with their front page but the versions advertised there are v.4.2.2 and v.5.0.0, which surprised me (cf. v.0.12.7). When I went to the downloads' section, I got totally confused by the overwhelming number of options, platforms, versions etc.
I trust my godlike ability to pick just the wrong option as well as my superpower of confusing everything to the edge of ridiculousness, so instead of cursing my rectum off, I prefer to ask straight how to obtain the requested version (v.0.12.7 for Win 8).
I would suggest nvm, it's great for node version management and installing any particular version of node you would like. https://github.com/creationix/nvm
If you're running 32-bit Windows, then you want the node-v0.12.7-x86.msi file in the directory in your link.
If you're running 64-bit Windows, then you want the node-v0.12.7-x64.msi file in the x64 subdirectory.
As #Ryan McDermott suggested, nvm is good. Another option, which I like, is nodenv: https://github.com/OiNutter/nodenv.
First, install nodenv. Then, install the plugin node-build (https://github.com/OiNutter/node-build). Then you can do the following:
nodenv install --list # list available node versions
nodenv install 0.12.7 # install the specified version
nodenv global 0.12.7 # use the specified version of node
I have installed Node.js on an Ubuntu 64bit server using a standard apt-get and would like to profile scripts through the "--prof" flag.
Web searching shows there should be a tool to process the v8.log output located in "deps/v8/tools/linux-tick-processor" but I don't seem to have any of those directories. Do they come with the native install? should they be installed separately? if so how?
Thank you
You need to download the source package with sudo apt-get source nodejs.The path you mentioned is in there.
You'll need to scons prof=on d8 in deps/v8 to build the debugger first, which might have some trouble on a 64-bit machine (v8 is 32-bit only), see here for more info.
Here's how I did it for Node.js 0.10.25 and 0.10.26:
I downloaded the source for Node.js that corresponds to the binaries I'm using. (I'm on Debian testing, which is a bit behind the releases from the Node.js web site.)
I checked the version of v8 bundled in the node sources. (Look at deps/v8/ChangeLog. It was 3.14.5 for Node.js 0.10.25 and 0.10.26.)
I downloaded this exact version of v8 from the v8 site.
Why? I tried running make native in Node.js deps/v8 directory but the Makefile was complaining about a missing test directory. From this we can infer that the Node developers are not including the entire v8 distribution. Once upon a time, with an earlier version of Node (0.8.something) I did build v8 from what was available in deps/v8 but this time I decided to use a different approach.
As explained in v8's build/README.txt, in the top level of the source tree for v8, I did:
$ svn co http://gyp.googlecode.com/svn/trunk build/gyp
(Linking my installed gyp to build/gyp as suggested in OrangeDog's answer did not work. That's why I did the above.)
I ran:
$ CXX=g++-4.7 make native
Why the CXX setting? I ran into a compilation problem right away when I tried with the default gcc. I checked the version. It was 4.8 and I remembered a story on Slashdot about how 4.8 was giving people trouble. So I installed 4.7. Worked fine.
I linked out/native/d8 to a location which is in my PATH. This is because the linux-tick-processor script does a poor job at finding d8. The simplest solution was to make it available in my PATH. Your mileage may vary.
After all this, linux-tick-processor can be used with the v8.log files that Node produces.
Either install the source package - sudo apt-get source nodejs, or switch to the official source as the ubuntu packages are very out of date.
To build d8, go to the deps/v8 directory.
Create a symlink at build/gyp to the directory where gyp can be found (e.g. /usr/bin).
Run make native.
Copy/symlink out/native/d8 to somewhere on your PATH.