I have this strange issue, where I am using 10th version of node (10.9.0) on a server, but things that should work or be supported in that version, are not.
For example, according to this table, this version supports Object.values(). On my local node installation - this indeed works, but on server, where I don't have much freedom about what software I am using, it does not.
Is there any way to truly verify used node version (node -v shows 10.9.0 as written above)? Maybe it's only a version of main binary yet all libs it's using are from version 6 (that one is also installed on that server)?
The process object that Node.js exposes has a lot of information including the version.
console.log(process.version); // v10.9.0
You can find the Node.js process.verison documentation here.
So within your application you can run that to see if it's truly what you expect.
You can also try running which node on your server. That should print the path it's using to find node. If you have multiple copies or installations of node, it might be using a path that is outdated. Making sure your path is up to date will solve that problem, and which node can help debug that.
Related
I am trying to host a node js (express) at dream host using shared unlimited plan. I was able to do most of the work. There is only one problem, dreamhost uses passenger to run node js app, and passenger does not support node 14+, so I have to stick with node v12.
The express js project I was building is built on typescript and I used node v16 to do all of the stuff installing, running etc. When I build the typescript, it uses an npm package exit-free-leak which uses FinalizationRegistry, hence requires node v14+.
So after building the app, When I run the app.js with node v12 it gives me the error that FinalizationRegistry is not defined. For now I am getting this error, but the exit-free-leak uses another node v14+ function "WeakRef".
So my question is how do I get around this issue while using node v12 ? is there anyway to polyfill these functions or disable use of the package exit-free-leak using tsconfig.json, or maybe an even better solution.
Unfortunately the answer to "how do I get around this issue while using node v12" is probably: "you don't".
Node 12 has been end-of-life for 9 months; given how fast the JavaScript ecosystem moves in general, it's unlikely that libraries will keep supporting that version for very long anyway.
You'd be best off asking Dreamhost about Node 16 or 18 support, or move elsewhere if they can't provide you with up-to-date runtimes that still get security updates.
i will try to give you a little of context.
With my team we are trying to migrate MUI v3 to v4 in a reactJs project. We did it with the project itself and it works! but, some kind of problems came up when we navigated to certain windows that use a certain library to work.
This library was developed by other guy that is not in the company anymore and we are not in touch neither, but, we have access to the library GitHub repository, them are two actually.
https://github.com/rjpizarro/forms
https://github.com/rjpizarro/make-request
i've never had to do this so, i decided to clone the project then install the dependencies and run it.
I'm using nvm so in that moment i was working with node v12 and i got some errors when i executed the npm start ("start": "webpack --watch").
If i use node 10 the scrips runs perfectly but in the entire project we are using node 12 so i'm not sure what is the problem here.
i'm wonder if it could be a problem when i'll try to migrate from MUI v1 to v4 and use the modified library into my project again, or in first place, why its working rigth now?
Anyway i just wanted to know, just if i need it, Could i use different versions of node in a library and then use other newer version into the entire project?
Could this make some negatives effect into my entire project?
Which is the best way to migrate MUI into this library and put it in my project again?
Each nodejs process (including all the modules/libraries it loads) has exactly one version of nodejs running. It isn't possible to have two separate versions of nodejs in the same process each running different parts of the code.
You could make two separate nodejs apps that each run under a different version of nodejs that communicate with each other via some interprocess communication, but they have to be two separate applications/processes.
If you want to run everything in one process (on one version of nodejs), then you will need to test and fix all your libraries to run on that one version of nodejs.
I am trying to use an oauth helper library called 'openid-client'. I am getting an error that reads in part '(TypeError): getCurves is not a function'. I poke around and find that getCurves is part of an inbuilt module of node.js 'crypto'.
If I console.log(typeOf(crypto.getCurves)) I get undefined. If I console.log(crypto) I see that crypto has many available methods but getCurves is not among them.
I am running node on my macbook and my project is a barebones npx create-react-app app with openid-client installed.
The node documentation outlines a way for determining if crypto support is unavailable, but that does not seem to indicate that crypto is unavailable for me.
I'm not sure why my version of node crypto does not have getCurves. Is there a way to install the correct version? Is there some sort of encryption restriction I am hitting due to OS? Any help appreciated.
node-openid-client is using APIs which are provided by Node and are missing in browser.
Node is being used by CRA as a development tool. App itself is running in browser and can't access Node's API-s, so it doesn't matter which Node version CRA is using.
When built, app is a set of JS files which can be served by a webserver (such as Nginx) directly without using Node at all.
So, this library can't be used with CRA apps.
https://github.com/panva/node-openid-client/issues/218
As you said, crypto is a built-in module, which means that its functionality depends on the version of node.js you have installed (you can check it via node -v from the shell or via console.log(process.version) at runtime).
Node.js API docs say that getCurves() was added in v2.3.0, so make sure your node is more recent than that.
I have a old Node.js application that I need to rebuild it to run it using my current Node installed. I have the node_modules folder. However, I cannot figures it was created using what version of Node. I searched for the term 'engine', but I had not success. Any ideas would be greatly appreciated.
The engines property can be used to define which versions of Node your application can run on, but it is optional. Without it, there is no way of knowing what version on Node the app was developed on. You could have switched Node versions during development and if there were no breaking changes, the application would have no idea.
Something you could try to do is look at the dependencies in your node_modules/ folder - if the dependencies are the same versions that you installed when originally developing, they might have engines properties in their package.json files that you could look at and piece together a picture of what Node version the application was developed for.
If you are trying to update the app to use a modern Node version, an easy way forward is to simply run the app, see what breaks, look up documentation to see what has changed between versions, and update your code until it works as expected.
TL;DR - There is no definitive way of knowing what the Node version was when the app was developed, unless it was documented by the developer.
If I update node or a package, will it affect the applications I have that are currently dependent on the previous node/package version I had? If yes, how do I fix this? Maybe like a virtual environment :)
You should be looking at the update from 2 standpoints.
1. Node itself
2. Updating NPM Packages
For instance, there is the Node LTS which at this time is 6.1.10 and then there is v7.7.3. If you desire total stability then use the LTS. As Cihan said above, upgrading Node can be a long process if you have a system running on an older version.
However, if you want to test out the new async/await (async functions) which is already in 7.7.3 and should be released officially in 7.8 then 7.7.3 is the way to go. But keep in mind some things just may not work as you think they should or you may get some wonky results.
Also be aware depending on your server or system the Node update works differently and make sure you read the documentation for that specific system you need to upgrade.
NPM is a different ballgame. You are reliant upon many different programmers or groups of programmers. The package is depending upon their capabilities and desire to maintain the backwards compatibility. Most package creators are really good about this. Some are not.
Take a for instance. MongoDB issued a really new driver which is an incredible upgrade from its previous one. The new driver contains ES6 and in conjunction with the co package, it is basically operating with promises.
Updating this package for MongoDB was essential for me. But it does maintain my previous code as well, (even though lots of it may be superfluous now!)
So when you think about updating Node..it is not the same as updating NPM modules. But if you wish, you can go to our project root where package.json exists and just type npm update and all packages will be updated. You can update to only a specific version - take a look here.
Remember also, NPM itself also requires updating from time to time.
So in summary:
Node Version - decide which one based upon needs, requirements and your own servers.
NPM as NPM also needs updating from time to time
NPM packages can be updated constantly with npm update or just update to a specific version number based upon the url above.
Not as confusing as it first seems, once one gets it all down straight :)
Good luck
It's possible that you have a package that is being used by another package which a version change could break it. There are several options, if this is a personal project then you would have to either reinstall the correct version of the package or see if there are updates available otherwise for the packages that broke.
It should not, because npm was made to resolve this issue: each project has its own dependencies, and it is totally independent with other projects.
In a word, no matter what you change, you do npm install in your project, npm will fix the dependency issue by itself (by checking your project's package.json)
npm-packages sometimes change or deprecate certain functions & functionalities in newer versions. If something stops working when you update a package, you must figure out from the documentation of the updated package on how to make it work again. Many packages might also give runtime information/errors in the console about functionalities that have deprecated or that have been marked for deprecation in future versions.
npm will download specific versions of a packages' dependencies (and thus you can often have multiple version of a certain package in one project), so you shouldn't need to worry about the dependencies of the packages you are updating, only about the changes of the package itself.
Certain npm-package versions only support certain versions of Node, so updating the node version might require updating some packages. If you switch the node version, it will also switch the npm version, which will then install the correct version of the package per node version.
Some Node.js functionalities might stop working if you update Node.js. In these cases you must refer to the Node.js docs for help. Sometimes updating Node.js from a old version to a new version in a project is a large and tedious task.