We Keep Coding

How to update multiple packages and dependencies with major version changes in Node/npm/React?

I have an old React project with multiple outdated packages both in package.json and in dependencies in package-lock.json. Many of this packages need to be updated to next major version or even to the many major version change (for example React from 16.14 to 18.2). Since this is major version changes npm update and npm outdated would not work. For updating single top-level package I have this and this and this answers with npm install the-package#version, but that will not update packages, that dependent on this package. There is also npm-check-updates utility that will update all packages to the latest version, but according to this it is better to update and test single package after major version changes. There is also multiple packages that required update to major versions changes and not listed in package.json and only listed in package-lock.json since they used only as the dependencies of some other packages (and in come cases I must update to the versions bigger than listed in the depency itself due to security scan requirements). This answer suggests manually updating package-lock.json and running npm install.
What is the best way of updating multiple packages and dependencies with major version changes including packages that are only listed as dependencies of some other packages (an may be referenced to lower major versions then required)? Is there a way to update dependency tree for single package (not all packages, not only this package)?
I have tried npm audit and npm audit fix --force but it work strange - do not update all packages, sometimes do not upgrade to the latest version (which I have to use by the security scan) and sometimes even downgrade package version. I have tried to update packages by the install --save the-package#version but this do not update dependencies and work only for package.json. So far I see the possible way like this
Update top-level packages with npm install and test
Manually check dependencies, update with npm install and test
Manually check dependency tree for packages from package-lock.json, update packages that dependent on them if they still references to old version manually change package-llock.json and test changes
This requires a lot of manual work for each package and manual editing of package-lock.json and probably not the best way. There is also one possible solution for dependencies of dependensies as mentioned in this answers using override section in package.json, but it is recommended only for security fixes. Is there a better way with more automation?

React update outdated dependencies flagged by checkmarx

In my project, I have some outdated dependencies that have been flagged by Checkmarx.
However, the dependencies flagged are in react-scripts version 4.0.3. For example, there are packages flagged within react-scripts, i.e ejs, immer, url-parse, debug and some more.
What would be the best way to upgrade these packages, individually or update to the latest react-scripts version, would that solve it?

I'm Ravid, a security researcher in Checkmarx.
Please allow me to address your question.
The best way to work around this issue is to update the "root" (react-scripts in this case) to the latest version.
Once you will update this package to its latest version (5.0.1), the transitive dependencies (AKA the children) will get updated accordingly.
For example, react-scripts uses react-dev-utils which uses immer, once updating react-scripts to the latest, you will notice it uses the latest version of immer.
Please note that a project might use a few different versions of the same package.
For example, react-scripts (latest) uses debug in versions 4.3.4 (latest) as well as 2.69 and 3.27.
It is important to remember then even after updating the "root" package there might still be outdated "children" packages, since some packages are still using vulnerable/outdated package versions.
An example of that would be:
As you can see, react-scripts (latest) uses webpack-dev-server (latest) which uses portfinder (latest) which uses debug 3.2.7 (NOT latest)
The "problem" relies on portfinder, which does not uses the latest version of debug.
Regarding breaking code after updating the dependencies, Checkmarx have an engine that will alert the method, line, and file that was broken At the moment, this feature is internal only but should be production-ready soon enough

how to solve this npm glob-parent problem

glob-parent <5.1.2
Severity: moderate
Regular expression denial of service - https://npmjs.com/advisories/1751
fix available via `npm audit fix`
node_modules/watchpack-chokidar2/node_modules/glob-parent
chokidar 1.0.0-rc1 - 2.1.8
Depends on vulnerable versions of glob-parent
node_modules/watchpack-chokidar2/node_modules/chokidar
watchpack-chokidar2 *
Depends on vulnerable versions of chokidar
node_modules/watchpack-chokidar2
watchpack 1.7.2 - 1.7.5
Depends on vulnerable versions of watchpack-chokidar2
node_modules/watchpack
I just install cookie-parser to cmd.
As mentioned above, there were 4 moderates.
My glob-parent -v is currently 7.19.1
It doesn't work 'npm audit' and 'npm audit fix'
How should I do?

In your package.json, add this target under scripts:
"preinstall": "npx npm-force-resolutions"
Then add this below the scripts:
"resolutions": {
"glob-parent": "^6.0.1"
}
One thing, I don't know if any dependent packages that use an older version will break because of 6.0.1.

I'm the person who wrote the fix for glob-parent that landed in glob-parent#5.1.2. There are (at least) three ways to address this.
First possibility: Update from watchpack version 1 to watchpack version 2. watchpack version 2 does not depend on a vulnerable version of glob-parent. Unfortunately, there is no CHANGELOG file in the watchpack repository, so you'll have to find the relevant breaking changes some other way. Maybe if you have excellent test coverage, you can rely on that. Or if your project is relatively new, then simply building it with watchpack version 2 to begin with will be the way to go.
The second possibility is that if watchpack is a development dependency only and not something used by the user-facing part of your app, then you probably don't need to worry about this at all and can ignore the message. I don't recommend this, but I also have to admit that npm audit warnings can be a little bit boy-crying-wolf sometimes.
The third option is to patch your vulnerable glob-parent with the fix. However, you have to know what your doing (particularly how npm works) to not shoot yourself in the foot and end up undoing the fix without realizing it. So this is also not something I recommend.
If you can update watchpack to 2.x, that is the way to go.

Use the following overrides and It will resolve the Issue
"overrides": {
"chokidar": "3.5.3",
"glob-parent": "6.0.2"
}
Add the above in your package.json and do npm update

The best way to resolve vulnerabilities in package-lock.json?

I am warned about vulnerabilities in the packages listed in the package-lock.json file of my Node.Js project.
I can follow the advice here and reinstall all the packages with npm install <package-name>, however, I also use other npm projects that use the older versions of those packages, which will not get reinstalled with a simple npm install.
Does it mean I have to go to package-lock.json and manually change all the dependencies to the latest version?
What if they break?
Isn't there a proper way of doing the updates that ensures you won't break the other packages dependent on the old versions?

If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency#latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!

Is bad practice to run "bower install" when deploying in production?

I am working on an application that uses bower.js; it's the first time I use bower, so please correct me if you see anything evidently wrong in my problem description.
------------------------------------------------
Coming from a Ruby background, I expect a package manager to have a .lock file, tracked under git, that tells me exactly which are the versions currently in use. This doesn't seem to happen with bower (am I right?).
A couple of days ago I deleted and re-cloned my repository, and ran bower install, thinking that such command would just install the required versions of the js components.
Then, today I did a one-line fix in a javascript file, compiled application.js using grunt watch, and realised that application.js was automatically filled up with tons of new code from bower component updates I wasn't aware of.
I found out that our bower components were under .gitignore, and that bower install, that I had run a few days ago, had actually updated two components without me noticing it.
When I realised what was happening, I immediately looked into our deployment procedure, which I paste here:
bundle install --path ${SNAP_CACHE_DIR}/.bundle
npm install -g bower grunt-cli
bower cache clean && bower install && bower list
bundle exec cap [our application name] deploy
Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?

Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?
Yes, this may happen and can cause problems. Although the impact will be limited as long as your dependency versions are specified as e.g. "~1.2.3", which will lock the major/minor version and only allow patch level updates.
In contrast to bower, the package manager normally used in node.js environments - npm - has a feature/command called npm shrinkwrap, which creates an npm-shrinkwrap.json file which locks down your dependency versions so that it is safe to run npm install afterwards.
This is probably what you would want.
However, bower as it stands does not have this feature yet - there is a discussion about it going on on Github e.g. here.
I think there currently are the following options to solve this problem in your situation:
Un-ignore and commit your bower_components (very ugly because of the huge amount of noise this produces in git).
Specify your dependency versions down to the patch level, e.g. "1.2.3" instead of "~1.2.3".
Culprit: If your dependencies have sub-dependencies, they might still be specified on the minor-version level, which means that even if your direct dependencies have a predictable version, your transitive dependencies may not.
Stop using bower and use npm instead (interface-/usability-wise, they are almost identical imho) and use npm shrinkwrap to lock down your dependencies.
Cheers, Alex