I am using express v4.16.4 in my node server.
It has pulled in cookie-signature v1.0.6.
I want to upgrade cookie-signature to v1.1.0 as it has a fix which I require.
What is the way to do that ?
I don't think i should do a npm install cookie-signature#1.1.0 as it would list cookie-signature in my app dependencies.
EDIT: this discusses the exact same problem that i am looking to solve. The accepted answer is using npm-shrinkwrap, and another top voted answer using package-lock.json , but both of these seem to have issues as discussed in respective comments.
Happy to close this as a duplicate.
You might also be able to solve the issue by adding a resolutions key in the package.json to "enforce" certain versions of dependencies:
{
"resolutions": {
"cookie-signature": "^1.1.0"
}
}
To actually make use of that, you have to use npm-force-resolutions in preinstall:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
See this post for further information: https://itnext.io/fixing-security-vulnerabilities-in-npm-dependencies-in-less-than-3-mins-a53af735261d
NPM 8 introduced "overrides" which allows you to override specific transitive dependencies of your direct dependency. For your usecase, you would declare something like below in your package.json.
{
"overrides": {
"express": {
"cookie-signature": "1.1.0"
}
}
}
More details # https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides
We had a very similar problem. Protractor 5.4.2 has a dependency on webdriver-manager#^12.0.6. In package-lock.json webdriver-manager was fixed to 12.1.5. However, we needed 12.1.7 in order to make it work with all the latest chrome versions.
We noticed, that npm would install version 12.1.7 when removing node_modules and package-lock.json, but we did not find a way to automatically update package-lock.json. So these are the steps we took:
Remove node_modules
Remove package-lock.json
Run npm install
Open package-lock.json and copy the webdriver-manager section to another file
Undo (git checkout) all changes in package-lock.json
Copy the saved webdriver-manager part back into package-lock.json
Remove node_modules
Run npm install
Check node_modules/protractor/node_modules/webdriver-manager/package.json that the right version was installed.
I think this workaround should work for express and cookies-signature as well.
Related
Have anyone been in this situation before ?
I run my code with CI/CD
after nest build, it gives me error :
node_modules/#types/superagent/index.d.ts:23:10 - error TS2305: Module '"buffer"' has no exported member 'Blob'. 23 import { Blob } from "buffer";
I don't know why? Please share if you got a solution for this one.
We had the same problem after upgrading nest 7.5.x to 8.0.0. The dependency "supertest" for "nestjs/testing" has a dependency on "#types/supertest" which wildcards "#types/superagent": "*", and that dependency has another wildcard dependency "#types/node": "*", but the types within #types/supertest actually require #types/node >=16.X.X.
So nestjs/testing -> supertest -> #types/supertest -> #types/superagent -> #types/node >= 16.X.X is your problem and error.
The comments mentioned are accurate because these package managers wildcard their dependencies to get the latest version of dependencies. They should but do not add peerDependencies with dependencies requirements such as "#types/node": "">=12.0.0 <16.0.0". Instead they say anything, "#types/node": "*" so the error is post package install, no npm warnings/errors. "It worked yesterday but not today" is your big red flag because when you ran npm install, with these wildcard dependencies even though you did not know it installed the latest version. Since it installed everything wildcard today, but not yesterday, it worked yesterday.
In addition, but also important is that you are have pinned #types/node <16.0.0 thus your error in combination with the other package changes.
One option: revert your package-lock.json changes and run npm ci
Another option: set your package.json dependency for #types/node to -> "#types/node": "^16.0.0",.
Another option: accept that wildcards are wrong and you don't trust what is going on there so pin the #types/superagent dependency to the one prior.
As for me and my family, we use nestjs with AWS lambda which runtime does not include nodejs 16, and not everyone on my team runs npm ci we more typically run npm install so the solution was
package.json
...
"devDependencies": {
...
"#types/node": "14.18.2",
"#types/superagent": "4.1.10",
"#types/supertest": "^2.0.11",
...
Upgrading #types/node to ^14.18.10 and typescript to ^3.9.10 worked for me.
"devDependencies": {
"#types/node": "^14.18.10",
"typescript": "^3.9.10"
},
Found on this discussion from Github
downgrading #types/superagent from v15.x.x to 14.1.14 solved the issue for me. v15 had some performance issues at the typing of this message
"npm i --save #types/superagent#4.1.14" did the trick
One tip is use npm view to get some info.
If you type
npm view #types/node
That shows the ts version compatibility. In my case, Is had to upgrade #types/node to 14.14.31, because I'm using ts 3.4.2.
if you have installed the npm, then delete the node_module file and use yarn install to add the new node_module and vice versa.
need pinned resolution feature of yarn, but also want to audit with npm audit? Is there a yarn alternative to npm audit? Or, alternately, will pinning resolutions of dependencies of dependencies work in npm?
Yarn doesn't have npm audit fix.
But here's how to do it by using npm – temporarily.
Generate a package-lock.json file without installing node modules
npm i --package-lock-only
Fix the packages and update the package-lock.json file
npm audit fix
Delete the yarn.lock file and convert package-lock.json file into yarn.lock
rm yarn.lock
yarn import
Delete the package-lock.json file
rm package-lock.json
For example:
yarn audit
38363 vulnerabilities found - Packages audited: 908342
Severity: 38352 Low | 11 Moderate
(I know. react-scripts is crazy...)
npm audit
npm ERR! code EAUDITNOLOCK
npm ERR! audit Neither npm-shrinkwrap.json nor package-lock.json found: Cannot audit a project without a lockfile
npm ERR! audit Try creating one first with: npm i --package-lock-only
npm i --package-lock-only
...
added 266 packages, removed 354 packages, updated 1653 packages, moved 1 package and audited 913793 packages in 54.304s
found 495 low severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details
npm audit fix
...
added 267 packages from 152 contributors, removed 355 packages and updated 1712 packages in 92.849s
50 packages are looking for funding
run `npm fund` for details
fixed 211 of 495 vulnerabilities in 913793 scanned packages
284 vulnerabilities required manual review and could not be updated
git status -s
?? package-lock.json
yarn import
yarn import v1.21.1
info found npm package-lock.json, converting to yarn.lock
...
success Saved lockfile.
✨ Done in 25.61s
rm package-lock.json
yarn audit / yarn install --audit has been available since yarn#1.12.0
https://github.com/yarnpkg/yarn/releases/tag/v1.12.0
Unfortunately no --fix option yet, but as workaround you can use https://www.npmjs.com/package/yarn-audit-fix
Yes, you can use yarn audit to audit for vulnerability but you can't fix the Vulnerabilities by using yarn audit fix as you can do in npm audit fix.
To fix the Vulnerabilities in yarn.lock file you have to reinstall the package(which is carrying the Vulnerability) to its newer version by using yarn add package_name
you can read the issue here => https://github.com/yarnpkg/yarn/issues/7075
I thinks that it's not ready on yarn. You can refer to the following issue.
https://github.com/yarnpkg/yarn/issues/5808
do a yarn audit and find the package(s) with vulnerabilities,
if they are in your package.json file
fix their version from there
else
they are dependencies of your packages so add this to package.json file
"resolutions": {
"**/package-name": "known-good-version",
"**/**/package-name": "known-good-version"
}
1st
Always use source control and check in your package.json as well as your yarn.lock and/or package-lock.json first and start with all committed files, so you can roll back if needed with ease.
How about a solution that does not add dependencies to your project (nor installing a third party library)?
yarn outdated # view
yarn audit # view
yarn install --audit # install
Prefer an interactive way to upgrade selectively with ease?
yarn upgrade-interactive
That might do all you require.
Oddly, you might find with a yarn audit following that command you still have some vulnerabilities not mentioned from the command yarn upgrade-interactive. In this case I'd first consider this:
yarn upgrade-interactive --latest
where that can be found
Still not quite good enough?
```
yarn upgrade --latest
```
I've seen a lot of other potential solutions, previously I'd just switch to npm from yarn temporarily as some users have suggested, then switch back to yarn. This has worked fine for me too. (Though annoying and not elegant)
There are packages out there that don't require install to run.
I haven't tried this one, it might be good too:
npm_config_yes=true npx yarn-audit-fix
ref
The key here is you are using npx to avoid installing as a dependency.
Many more solutions are possible. npm and yarn both are package managers, dependency management is a very difficult thing to do, automagically fixing these dependencies will always be a difficult problem to solve. Thus I recommend a little research on how they are actually solving these problems if you have the time. You might find yourself not liking how they do things.
Ultimately, as long as you can roll back you can try a lot of these out and see for yourself. Some packages severity might not need fixing, sometimes libraries do not have solutions available yet, then you need to consider removing their usage in your codebase. In theory, less is more, less dependency on libraries, which use libraries, which use libraries.... becomes a much smaller surface for attackers to target. Also, it's not advisable to use libraries from untrusted sources, npm, yarn and more cannot know everything, nor right away, so keep that in consideration too.
I created a script command into the package.json file to fix it. It creates a copy of yarn.lock as package-lock.json, removes the issues and then re-creates yarn.lock.
"resolve:security": "npm i --package-lock-only && npm audit fix && rm yarn.lock && yarn import && rm package-lock.json",
I hope it helps :)
You can use yarn audit as mentioned in the other answers, however, there is a different way to solve them...
You will need to add the resolution instruction to specify the version of the library that the vunerability was solved and the path of the dependency (because the library can be a dependency of another dependency, for example:
Considering part of some package.json below
{
"name": "project",
"version": "1.0.0",
"dependencies": {
"left-pad": "1.0.0",
"c": "file:../c-1",
"d2": "file:../d2-1"
},
"resolutions": {
"d2/left-pad": "1.1.1",
"c/**/left-pad": "^1.1.2"
}
}
More details can be checked directly in the documentation: Doc
Yarn doesn't support the fix at the moment,
Workaround
create a package-lock.json file using npm.
fix the packages
remove the package-lock.json.
.
npm i --package-lock-only
npm audit fix
rm package-lock.json
and start
yarn start
Yarn also has yarn audit mechanism, but it doesn't have yarn audit fix mechanism. So in most cases you have to fix these issues manually. This is how it works. For example we'll demonstrate it using minimist package:
Add a resolutions key in your package.json file:
Adding dependency(say minimist) directly as key value .This resolution will override minimist entirely in your project.
{
"resolutions": {
"minimist": "^1.2.5"
}
}
In most cases, there can be multiple dependencies in a project that use the same secondary dependency, however, they might use different versions of those dependencies. Thankfully, yarn/npm allows us to have selective dependency resolutions.
The format to define resolutions is the following:
/* package.json */
{
"resolutions": {
"<package>/**/<dependency>": "<version>"
}
}
Let’s say for example, we have a dependency A and B and both of them depend upon another dependency C.
Then our resolutions field would look like:
/* package.json */
{
"resolutions": {
"A/**/C": "2.0.3", // A works fine with the latest version of C
"B/**/C": "1.9.0" // latest stable version for C for dependency B
}
}
Let's further see how it works with an example of package-merge-lodash-4 package. If audit says that lodash#3.9.3 has vulnerabilities and suggests us to upgrade lodash#3.9.3 -> 4.17.12.
We can write our json file's resolutions only for the concerned package as below:
{
"resolutions": {
"package-merge-lodash-4/**/lodash": "4.17.12"
}
}
How to use Selective dependency resolutions in npm?
add npm-force-resolutions to the preinstall script after you added resolutions key to package.json file, so that it patches the package-lock file before every npm install you run:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
To confirm that the right version was installed, use the below command
npm ls <vulnerable dependency>
npm ls lodash
Resources:
Selective dependency resolutions
Yarn - How to fix security issues
How to fix security vulnerabilities in NPM/Yarn dependencies
Yarn audit fix: workaround
What's the difference between tilde(~) and caret(^) in package.json?
Semver explained - why is there a caret (^) in my package.json?
Try using,
yarn upgrade-interactive --latest
Will install all the latest dependencies.
I have a package.json file that lists all the dependencies I have with *'s, but I want the latest packages. I tried:
npm install --save
But that didn't replace the *'s in the file. I tried with empty strings as well, that didn't work.
Older versions of npm will update package.json when you run npm update --save, but this appears to be broken in recent versions.
Alternatively, npm-check-updates can update your package.json.
npm understands some special keywords in its package.json one of them being latest
so you can edit your file manually with something like this :
'dependencies': {
'jquery': 'latest'
}
this would always give you the latest available version of jquery no matter what.
I'd suggest you replace everything with * and run npm update --save.
This will write down the versions of the dependencies.
So
"dependencies": {
"mongo": "*"
}
will become something like
"dependencies": {
"mongo": "3.0.0"
}
EDIT: one user made a good point, * can get you in some incompatibility problems so you might want to downgrade or need to fix stuff after.
I need to know if the following behavior is normal.
When I npm install, each package from my package.json and the dependencies, don't get installed nested anymore, but each dependency is installed in the node_modules directory. That makes my node_modules directory blown and look like this:
This happened since I updated npm and node.
Now I run:
npm -v 3.3.6
node -v 4.2.1
python 2.7
windows 7
wamp
My package.json file looks like this:
{
"private": true,
"devDependencies": {
"gulp": "^3.8.8"
},
"dependencies": {
"laravel-elixir": "^3.0.0",
"bootstrap-sass": "^3.0.0"
}
}
It's the standard laravel package.json file.
Is there a way to have nested directories again, because I don't like such a blown article with over 100 sub directories.
Update: As Erik Pukinskis mentioned in the comments:
As of npm 3.5, support for --legacy-bundling has been dropped.
Yes, there is a way to have nested directories again by changing npm's (version 3 as of this writing) default behaviour:
Delete the currently present node_modules folder.
Tell npm to install with legacy bundling for this one install:
npm install --legacy-bundling
A "permanent" alternative:
Set your npm config to always use legacy bundling...
npm set legacy-bundling=true
.. and run as usual:
npm install
Note: fetching dependencies with legacy bundling will take a lot more time because many several different versions of the same dependencies will be installed.
Disclaimer: As a non-Windows user I have no need for flat dependencies and want to find self-declared dependencies with ease in favour of automatic deduping. Since installing npm dependencies without legacy bundling already takes an incredible amount of time I'm usually willing to spend those extra minutes install time. It gets back down to 5 directories from previously 700+ (...) in a Laravel Elixir setup with bootstrap (non-sass), font-awesome and jquery added.
That's the new behavior of npm 3 as per this npm blog.
I have an application which has the usual set of dependencies on third party modules (e.g. 'express') specified in the package.json file under dependencies. E.g.
"express" : "3.1.1"
I would like to structure my own code modularly and have a set of local (meaning on the file system I am currently in) modules be installed by the package.json. I know that I can install a local module by running:
npm install path/to/mymodule
However, I don't know how to make this happen via the package.json dependencies structure. Using the --save option in this command is simply putting "mymodule": "0.0.0" into my package.json (doesn't reference the filepath location). If i then remove the installed version from node_modules, and try to re-install from the package.json, it fails (because it looks for "mymodule" in the central registry, and doesn't look locally).
I'm sure the is a way of telling the "dependencies": {} structure that I want it to be installed from a file system path, but don't know how.
Anyone else had this problem?
Thanks.
npm install now supports this
npm install --save ../path/to/mymodule
For this to work mymodule must be configured as a module with its own package.json. See Creating NodeJS modules.
As of npm 2.0, local dependencies are supported natively. See danilopopeye's answer to a similar question. I've copied his response here as this question ranks very high in web search results.
This feature was implemented in the version 2.0.0 of npm. For example:
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
Any of the following paths are also valid:
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
syncing updates
Since npm install <folder> adds the package in the directory as a symlink in the current project any changes to the local package are automatically synced.
See: Local dependency in package.json
It looks like the answer is npm link: https://docs.npmjs.com/cli/link
I couldn't find a neat way in the end so I went for create a directory called local_modules and then added this bashscript to the package.json in scripts->preinstall
#!/bin/sh
for i in $(find ./local_modules -type d -maxdepth 1) ; do
packageJson="${i}/package.json"
if [ -f "${packageJson}" ]; then
echo "installing ${i}..."
npm install "${i}"
fi
done
After struggling much with the npm link command (suggested solution for developing local modules without publishing them to a registry or maintaining a separate copy in the node_modules folder), I built a small npm module to help with this issue.
The fix requires two easy steps.
First:
npm install lib-manager --save-dev
Second, add this to your package.json:
{
"name": "yourModuleName",
// ...
"scripts": {
"postinstall": "./node_modules/.bin/local-link"
}
}
More details at https://www.npmjs.com/package/lib-manager. Hope it helps someone.
You can just add to your package.json file in your project
"package-name" : "path/to/package"
and then run npm i in your project
At work we have a common library that is used by a few different projects all in a single repository. Originally we used the published (private) version (npm install --save rp-utils) but that lead to a lot of needless version updates as we developed. The library lives in a sister directory to the applications and we are able to use a relative path instead of a version. Instead of "rp-utils": "^1.3.34" in package.json it now is:
{
"dependencies": { ...
"rp-utils": "../rp-utils",
...
the rp-utils directory contains a publishable npm package
use install-local
I had issues with conflicting react installations from the local dependency.
I solved the error by using install-local npm package. This package does not create symlinks, which solved my issue.
Steps:
run npm i -g install-local
run npx install-local --save <local-path> inside the target repository to install the local dependency
Further reading: https://www.npmjs.com/package/install-local
The error I received, when trying to install the local package with npm install --save <local-directory>:
Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
You might have mismatching versions of React and the renderer (such as React DOM)
You might be breaking the Rules of Hooks
You might have more than one copy of React in the same app
If it's acceptible to simply publish your modules preinstalled in node_modules alongside your other files, you can do it like this:
// ./node_modules/foo/package.json
{
"name":"foo",
"version":"0.0.1",
"main":"index.js"
}
// ./package.json
...
"dependencies": {
"foo":"0.0.1",
"bar":"*"
}
// ./app.js
var foo = require('foo');
You may also want to store your module on git and tell your parent package.json to install the dependency from git: https://npmjs.org/doc/json.html#Git-URLs-as-Dependencies