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
Currently, every dependency and devDependency is used when determining whether a Node version is compatible.
In some cases this doesn't make sense and we can filter them out internally (the first thing that comes to mind are any @types/{package} dependencies -- they're just TypeScript files that don't care about Node versions).
In other cases, a user might not care about certain packages and don't want to see them in the output. Or maybe they don't want to see packages that don't specify an engines filed (the ones that show undefined in the table output).
In a third case, the user might want to see only packages that are not compatible with the given Node version (or the opposite -- only the ones that are).
We should implement some kind of --filter option that we can pass a string of package names to that won't be included in the final output. Bonus points if the user can use RegEx or glob patterns (ie, @package-name/*).
We could also add an --only option that could take some pre-set options (such as compatible, not-compatible, defined, undefined, etc). Or maybe it's incompatible? I don't know, maybe we pick a word that's easier to type?
Possible Implementation
The main depngn function could take a second argument -- options -- that should be an object (so we can extend it later) with a filter field (an array of strings to ignore). In the cli function, we could parse a --filter arg and convert the string to an array and pass it to the depngn function. Beyond that, nothing would have to change.
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Describe your request
Currently, every
dependency
anddevDependency
is used when determining whether a Node version is compatible.In some cases this doesn't make sense and we can filter them out internally (the first thing that comes to mind are any
@types/{package}
dependencies -- they're just TypeScript files that don't care about Node versions).In other cases, a user might not care about certain packages and don't want to see them in the output. Or maybe they don't want to see packages that don't specify an
engines
filed (the ones that showundefined
in the table output).In a third case, the user might want to see only packages that are not compatible with the given Node version (or the opposite -- only the ones that are).
We should implement some kind of
--filter
option that we can pass a string of package names to that won't be included in the final output. Bonus points if the user can use RegEx or glob patterns (ie,@package-name/*
).We could also add an
--only
option that could take some pre-set options (such ascompatible
,not-compatible
,defined
,undefined
, etc). Or maybe it'sincompatible
? I don't know, maybe we pick a word that's easier to type?Possible Implementation
The main
depngn
function could take a second argument --options
-- that should be an object (so we can extend it later) with afilter
field (an array of strings to ignore). In thecli
function, we could parse a--filter
arg and convert the string to an array and pass it to thedepngn
function. Beyond that, nothing would have to change.Code of Conduct
The text was updated successfully, but these errors were encountered: