We Keep Coding

Should I update my peer dependencies while upgrading RN version?

I tried upgrading one of my legacy projects from RN 0.61.x to 0.70.x, react 16 to react 18 recently.
I noticed that there were a lot of dependencies which relied on older RN version in their peer dependencies.
This throws an error in npm 8. I found this https://github.blog/2021-02-02-npm-7-is-now-generally-available/ and they say we can use
You have the option to retry with --force to bypass the conflict or --legacy-peer-deps command to ignore peer dependencies entirely (this behavior is similar to versions 4-6)
I am confused as to which route to take solve for the peer dependency issues also or just ignore them.
Which approach should I use and why?
So far I have moved many dependencies to use the new react version but some of these dependencies depend on other dependencies which use old react versions as their peers.
Some are internal libraries I maintain and others are external ones.

This site might help you to upgrade between certain react native versions:
https://react-native-community.github.io/upgrade-helper/
But I think you will find other issues related to your own case. Better create new react native project with latest version and move your files manually from old to new project. Also install your libraries one by one to test if it breaks or not.

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!

Yarn sub-dependency control

When reading yarn docs (the part: Selective dependency resolutions) I found usage case:
Your dependency defines a broad version range and your sub-dependency
just got a problematic update so you want to pin it to an earlier
version.
So there it is: let's say I installed dependency, and this dependency has its sub-dependencies which are defined by dependency lockfile. When the dependency has defined broad version of its sub-dependency the issue can occur, ie. sub-dependency can be bumped and it can be destructive to its mother dependency (then the whole app goes down) on the fresh install. This means that I have no control over sub-dependency version. On every fresh yarn install it can be very different even though I have my own lock file.
Please help me understand,
first of all, even though I have my own lockfile I cannot control sub-dependencies versioning?
second, is there a way to control it somehow in order to prevent uncontrolled sub-dependency bumping? Selective dependency resolutions is a way to control it but only after finding that error occurs and setting resolutions for ALL sub-dependencies makes no sense.
Expected behavior: lock sub-dependency to flat versions as it is with first-level dependencies so when fresh install occurs it will install not only exact dependency but also the same sub-dependency on other machine (version control).
Thank you!