You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have detected some problem with the current way ncu handles the --reject parameter when an empty string ("") is provided for this parameter; Currently it checks the dependencies on the home directory of the current user (or somewhere else that is not the current directory). (even if you configure --cwd correctly), I have checked the --loglevel silly for correct detection of the package.json intended to upgrade to be correct.
Steps to reproduce:
Create a new project (I am using yarn package manager but npm also will work) and add a outdated dependency for later checking with ncu:
OR, at least, it should warn you about the empty --reject parameter and work this way (or warn about this behaviour somewhere in the docs, idk). One thing is for sure, the current behaviour looks faulty to me.
This turned out to be caused by a bug in which options got duplicated. For some reason the duplicated empty reject excluded all dependencies. My previous solution didn't cover all options. Now I have generalized it and added the necessary tests.
I have detected some problem with the current way ncu handles the
--reject
parameter when an empty string (""
) is provided for this parameter; Currently it checks the dependencies on the home directory of the current user (or somewhere else that is not the current directory). (even if you configure--cwd
correctly), I have checked the--loglevel silly
for correct detection of thepackage.json
intended to upgrade to be correct.Steps to reproduce:
Create a new project (I am using yarn package manager but npm also will work) and add a outdated dependency for later checking with ncu:
Current Behavior
It outputs the following:
Expected Behavior
It should output the following:
OR, at least, it should warn you about the empty
--reject
parameter and work this way (or warn about this behaviour somewhere in the docs, idk). One thing is for sure, the current behaviour looks faulty to me.Thanks!
npm-check-updates
node >= 14
The text was updated successfully, but these errors were encountered: