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.
Related
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?
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
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!
I started react-native project, and decided to test native-base library. Installing it and its dependencies resulted in changes to both ios and android folders. I'm not sure should I put these changes to version control or not?
The changes were:
ios:
ios/AppName.xcodeproj/project.pbxproj: I see hashes with fonts added
ios/AppName/Info.plist: Fonts are added here too inside tags
android:
android/app/src/main/assets/fonts/[20 different fonts]
So apparently, installing react-native native-base resulted in getting some fonts to the native folders? The best practise standard .gitignore files for react-native projects does not ignore these files, hence my version control client is showing the files to me. But I wonder if all of those changes were made only because of installing some third party libraries, then should I put them to version control? As the peer coders will also install those, and they should get the same files, right?
What I worry is that some important files in the native directory will become unsynced between the developers of this project. If they install the native-base, and it results in change for some core files in ios side, then that change might not be exactly the same (for example, there might have been minor version update etc.). I don't really know what to do, please help!
Apparently a very similar issue has came up for others too.
One possible solution is to check, whether it's a compatibility issue and downgrade React Native for start.
The other potential solution might be is to reinstall React Native with NPM:
npm install react-native --save
If this doesn't help, try again, but before installing React Native with NPM, remove package-lock.json and the node_modules directory (on Linux):
rm -rf package-lock.json node_modules
If you use Yarn, try to use NPM instead and see whether this resolves your problem.
I'm a relative newcomer to the node community. I recently got on board so that I could put together a build for a complex web application that's been under development for several years. The two key tools in my build are Grunt and Browserify, but the application uses jQuery, Backbone, d3 and a smattering of other libraries and plugins as well.
A problem that I've been running into is this: by default, when I install and save a package with npm, it sets up the package with a semver expression that captures all future releases of the package whenever you run npm update. Like this article explains well, that may seem like a good thing at first ("give me this package and all future upgrades"), but it exposes your own application to any non-backwards compatible updates the package maintainer makes... The article also provides some recommended best practices, but it was written almost 4 years ago to the day; I'm hoping there are other, newer ideas.
What sort of solutions do you use to resolve this issue? I can't keep wasting time updating my software every time a breaking change is made in a library I rely on. I want to update when I am good and ready, not whenever I run npm update.
Use npm shrinkwrap to save the tree of dependencies containing the exact versions, so when you npm install it'll use those exact versions.
The npm outdated command will tell you what packages are outdated.
Instead of npm update which updates all your packages, update specific packages with npm install <pkg>#<version> --save