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.

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?

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

Why one package's dependency impact another

I have a folder which name is project.
I use "yarn add" to install two packages (antd and antd-mobile)，both of them have a dependency which name is rc-checkbox.
antd uses "rc-checkbox": "~2.1.5".
antd-mobile uses "rc-checkbox": "~2.0.0".
After running the command, project/node_modules has a 2.0.0 version rc-checkbox folder, and project/node_modules/antd/node_modules has a 2.1.5 rc-checkbox folder.
The weird thing is no matter which one I install first, antd-mobile's 2.0.0 rc-checkbox will be installed at project/node_module. And when I run the project, antd uses the rc-checkbox which version is 2.0.0 (it is supposed to use 2.1.5) and it causes the bug.
So why would this happen? I think two packages use same another package with difference version should not impact each other.

Copy from Here
Version locking
yarn generates yarn.lock after each installation which persists ALL versions of installed packages (as you probably know package can has also dependencies and dependency can have also dependency) so it can build up infinite tree of dependencies which can lead to very bad conflicts. Let's imagine this scenario
- lodash^1
- super_module#0.0.1
- - lodash#1.0.0
- another_module#0.0.01
- - lodash#1.x.x
Imagine scenario when maintainer of another_module decides to bump lodash to breaking changes version 1.2.0 what can happen is that npm in old days could fetch 2 different instances of same library, and 2 different version which could lead to extremely weird behavior. Because as you don't have exact lock in your module (you accept any semver version ^1.x.x and ^2.x.x so that means both sub modules would satisfie your requirements but fetch different version. Yarn will lock your yarn.lock AT THE TIME OF AN ADDING new package to the project, that means when other developers on your project will checkout the project he will also have same yarn.lock and yarn will ultimately "mimic" the state of package how they were installed when you committed yarn.lock on other hands NPM just looks to the semver satisfaction and can fetch 2 different version for 2 developers (assuming that in time packages are upgrading)

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!