We have a project built with NodeJS. With time the version upgrades are very necessary but while updating the version, if we do not have enough test cases, something might break and we may know it far later. Such a scenario was introduced when replaceAll method was used in some part of the code. But replaceAll is not supported until NodeJS 15 or later. So we run into trouble after merging the code.
Can we check whether the NodeJS code works or not for a specific version?
Demonstration:
I've created a repository on GitHub for this with a workflow to demonstrate the problem. See this run https://github.com/kiranparajuli589/node-check/runs/7573211393?check_suite_focus=true
Here I've used Node 14 and properly configured the engines keyword in the package.json but still, the linter is not reporting about the usages of such functions that are not available.
Related
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've been going through the documentation at https://bazelbuild.github.io/rules_nodejs/ in order to put together a small web based application. I've got babel building the JS code, and http_server serving it, and ibazel watching it, and everything is working as expected: when I make a change, ibazel notices it and restarts the http_server rule.
The next thing I wanted to look at is getting autoreload in the browser so that the browser would automatically refresh when the change was compiled. My understanding is that this requires the http server to not be killed by ibazel, but instead to stay up and trigger a refresh via the ibazel_live_reload mechanism. I believe that http_server doesn't support this, but ts_devserver is explicitly mentioned in several places. However, ts_devserver doesn't seem to be maintained anymore (although I did find a devserver EXE in the npm package, there isn't a bazel rule that I saw to use it).
Is there a third party live development server that supports the ibazel reload mechanism - or am I missing something completely obvious?
Disclosure, I'm a core maintainer on rules_nodejs
As of rules_nodejs v3.0.0, ts_devserver has been renamed to concatjs_devserver to try and better namespace it (it has little to nothing really to do with Typescript). Its docs can be found here.
Note though that the concatjs_devserver comes with some compatibility gotchas, all dependencies have to be in named AMD/UMD or goog.module format for example, and may be tricky to use unless following the rest of the google3 toolchain.
We've (as the maintainers of rules_nodejs) tried not to wrap an existing devserver and publish it as of yet for various reasons, but it's something that has come up in discussion. I'm currently investigating some options in this space.
I'm not aware of any published devservers that currently support the ibazel protocol, there is a wrap of browsersync in the Angular Components repo which you may find useful.
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.
I have an API server built with loopback.io (NodeJS) version 3.0.0, however latest version is 3.17.1 and there obviously have been a lot of security and bug fixes over all this time, which makes me feel on potential danger and outdated.
How can I update the framework without affecting my own code? How do other frameworks deal with this kind of issue?
Your code should be completely separate from the loopback.io code. As such, you should be able to do npm update looback.io from the right directory and it should update the loopback.io code and not affect your code at all.
Now this assumes you were using loopback.io as a library that you loaded with require() and that you did not modify the actual loopback.io code yourself in any way.
Before upgrading, you will want to examine the release notes for the revisions of loopback.io since the version you originally installed and make sure there are only bug fixes and no compatibility issues with code written for prior versions (e.g. API changes, etc...). If there are any API changes or "breaking" fixes, then you may have to slightly modify your code in that one area to update to the new API.
Then, after upgrading, run your unit tests to see if everything is still working as you would expect.
Do you know any tool that monitors breaking changes in github npm or bower projects?
I'd like to list all changes from commit history that are marked with breaking change and list them.
I am using npm-check-updates, that tells me what is new, but it doesn't tell me what has been changed since.
Recently, I have found greenkeeper.io, but as far as I know it doesn't list what is new, it just simply does upgrade and see if your tests are still running. If tests fails, you have to fix it yourself.
In ideal opensource world author marks every breaking change. Also he writes code without bugs. In the real world is not true. You have opensource packages for free, but with possible bugs and undocumented changes API.
There is only working answer, testing your application for each dependencies update. You should have tests and shrinkwrap file.
greenkeeper.io is amazing tool. It makes pull request with dependency changelog. Check example