I have vue.js application. when using
yarn install.
Then, warning shows up as below
warning #vue/cli > #vue/cli-ui > vue-cli-plugin-apollo > apollo > git-parse > babel-polyfill > core-js#2.6.11: core-js#<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js#3.
warning #vue/cli > #vue/cli-ui > vue-cli-plugin-apollo > apollo > git-parse > babel-polyfill > babel-runtime > core-js#2.6.11: core-js#<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js#3.
in my package.json file, the version of core-js is already ^3
"dependencies": {
...
"#vue/cli": "^4.2.2",
"core-js": "^3",
...
},
I wonder if there are anyone who got same issue, and I appreciate it if someone would have any info, any solutions.
It is not a problem with your application or library itself, it's a warning by a dependency of a dependency of a dependency (and so on) of a library you added.
Try perform a security update with:
npm audit
or
yarn audit
then:
npm audit fix
or
yarn audit fix
which will try to solve your security issues.
Remember to test everything before committing, because there could be breaking changes.
Related
The package manager npm gives a high severity vulnerability which I don't know how to fix. The advised forced fix wants to install a very old version of expo. Node is up to date (v18.14.1). There seems to be an outdated version reference in 'find-babel-config' to JSON5.
Does anyone have an idea how to fix this dependency? I tried reinstalling and updating npm, including manually deleting node_modules and package-lock.json, cleaning npm cache and updating expo.
npm audit
# npm audit report
json5 <1.0.2
Severity: high
Prototype Pollution in JSON5 via Parse Method - https://github.com/advisories/GHSA-9c47-m6qq-7p4h
fix available via `npm audit fix --force`
Will install expo#1.0.0, which is a breaking change
node_modules/babel-preset-expo/node_modules/json5
find-babel-config <=1.2.0
Depends on vulnerable versions of json5
node_modules/babel-preset-expo/node_modules/find-babel-config
babel-plugin-module-resolver 2.3.0 - 4.1.0
Depends on vulnerable versions of find-babel-config
node_modules/babel-preset-expo/node_modules/babel-plugin-module-resolver
babel-preset-expo *
Depends on vulnerable versions of babel-plugin-module-resolver
node_modules/babel-preset-expo
expo >=14.0.0
Depends on vulnerable versions of babel-preset-expo
node_modules/expo
When I run
npm audit
It tells me I have a critical vulnerability in lodash. When I run
npm ls lodash
I have 47 instances of lodash being deduped.
How can I tell which of my dependencies are holding on to the vulnerable version?
If you temporarily add the vulnerable package at the patched version:
"lodash": ">=4.17.21",
to your package.json and then run npm update <VULNERABLE_PACKAGE> for the vulnerable package. NPM will update all the child dependencies it can.
You can then run npm outdated --depth=5 <VULNERABLE_PACKAGE> and it will show which dependencies are forcing an earlier version.
Context
I joined a new project where I was asked to upgrade React from version 17 to 18. After upgrading react and react-dom and some other dependencies I got some warnings, which had to do with dependencies.
npm install react#latest react-dom#latest
Some of them I was able to resolve easily, by updating some packages. This was until I tried resolving the following warning:
npm WARN Conflicting peer dependency: react#17.0.2
npm WARN node_modules/react
npm WARN peer react#"^16.3.0 || ^17.0.0" from react-side-effect#2.1.1
npm WARN node_modules/react-helmet/node_modules/react-side-effect
npm WARN react-side-effect#"^2.1.0" from react-helmet#6.1.0
npm WARN node_modules/react-helmet
Already I am a bit surprised by the react#17.0.2. Apparently there is another version of React still in dependencies, that is required by another package.
Package that requires React 17.0.2
"<CUSTOM PACKAGE MADE BY SOMEONE ELSE>": {
"version": "0.3.0",
"resolved": <LINK>,
"integrity": "sha1-Ah72HLxApcdcSPGRIE/L7wjy8Ec=",
"dependencies": {
<CUSTOM PACKAGE MADE THE SAME PERSON 2>: "^0.1.6",
"react": "^17.0.2",
"react-dom": "^17.0.2",
"react-scripts": "5.0.0"
}
},
The actual dependency
"react": {
"version": "17.0.2",
"resolved": "https://registry.npmjs.org/react/-/react-17.0.2.tgz",
"integrity": "sha512-gnhPt75i/dq/z3/6q/0asP78D0u592D5L1pd7M8P+dck6Fu/jJeL6iVVK23fptSUZj8Vjf++7wXA8UNclGQcbA==",
"requires": {
"loose-envify": "^1.1.0",
"object-assign": "^4.1.1"
}
Ancillary Question
Would having 2 versions of React in your package-lock.json not cause problems? I can't imagine these two version be used simultaneously. My guess would be that in this case this should be a peer dependency, am I correct to assume that?
Attempts
At first I thought that I could not update React yet, until react-helmet would be patched. I let my colleagues know, and they all said that another project also used react-helmet and they were able to update React. What?! Great impression on new colleagues 😄.
Indeed opening the other project and installing the new React version there did not cause the same warning.
Question
As an experiment I decided to remove the package-lock.json entirely. This resulted in the same errors. Removing the package-lock.json and the node_modules resolved it however! Why is this the case? The package that requires React 17.0.2 is still there as is the dependency for React version 17.0.2. Yet somehow, it is no longer a problem.
Any help to understand why this would resolve the situation would be greatly appreciated.
Note
react-helmet seems to be unmaintained, so will need to be removed eventually. This is not what my question is about.
Apparently removing the node_modules and package-lock.json did not help at all. Removing both does not trigger the warning the first install. Once you run npm install again, the same warning will show.
So it seems the warnings do not show up at the first 'clean' install. This also seems to be true at the other project, however there is something more going on there.
In this case it will probably mean that we will need to replace react-helmet with react-helmet-async and update the version of the custom package.
In application, I come across some issue when installing npm packages.
the package.json goes as following:
"dependencies": {
"#angular/cdk": "7.2.1",
"privateLib": "19.0.0",
}
I only show the critical part and hide other things. The privateLib is one private package you can ignore the name.
And after npm install, it reports the following warn message:
npm WARN privateLib#19.0.0 requires a peer of #angular/cdk#7.3.7 but none is installed. You must install peer dependencies yourself.
And I checked the installed #angular/cdk is version 7.2.1.
The confusing points is that, inside the privateLib, its own package.json config goes like this:
"dependencies": {
"#angular/cdk": "7.3.7",
}
I checked there is no #angular/cdk package inside privateLib. So why it doesn't install its own dependency of version 7.3.7 in a nested way. This behavior is not same as the npm3 document: https://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html
I'm using npm v6.
Indeed, per https://blog.npmjs.org/post/110924823920/npm-weekly-5:
We will also be changing the behavior of peerDependencies in npm#3. We won’t be automatically downloading the peer dependency anymore. Instead, we’ll warn you if the peer dependency isn’t already installed. This requires you to resolve peerDependency conflicts yourself, manually, but in the long run this should make it less likely that you’ll end up in a tricky spot with your packages’ dependencies.
Try https://github.com/spatie/npm-install-peers to facilitate.
Note: this is a one-way operation. Once you eject, you can’t go back! … At this point you’re on your own.
Claims the CRA docs. However, I don't see why this is. If I am using a VCS, what is preventing me from rolling back the changes made by running npm run eject? This would imply there's something outside the project that affects it, which violates some vague notions about principles of modern web dev that I have in my head..
You can revert eject if you revert the changes in VCS.
eject will just copy configuration files to your working directory so that you have edit them the way you want.
Keep in mind that once you eject, there could be changes in structure in node_modules as scripts will be looking in different paths. Also, node_modules are generally not tracked in version management systems. So after you revert the eject, you might have to install dependencies with npm install or yarn
If that doesn't work, try removing node_modules directory and run npm install or yarn again.
Basically, everything that is tracked in version management systems can be reverted back.
In this case I think a picture begins to explain it. It appears to compile somewhat your app and package.json. Although my node_modules folder appears to get bigger, if I deleted it and type yarn it comes back but only 29 MB this time instead of the larger 175 MB you can see in the screenshot prior to this.
➜ aminosee copy git:(master) ✗ yarn
yarn install v1.13.0
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning " > #typescript-eslint/eslint-plugin#1.6.0" has unmet peer dependency "typescript#*".
warning " > #typescript-eslint/parser#1.6.0" has unmet peer dependency "typescript#*".
warning "#typescript-eslint/eslint-plugin > #typescript-eslint/typescript-estree#1.6.0" has unmet peer dependency "typescript#*".
warning "#typescript-eslint/eslint-plugin > tsutils#3.10.0" has unmet peer dependency "typescript#>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev".
[4/4] 🔨 Building fresh packages...
✨ Done in 68.43s.