npm
[DOCS] npm search --long flag has no effect
Is there an existing issue for this?
- [X] I have searched the existing issues
This issue exists in the latest npm version
- [X] I am using the latest npm
Current Behavior
This could also be a feature request or a docs update depending how you look at it...
When calling npm search with the --long flag, e.g.
> npm search --long --json --searchlimit 1 color
I get this output, which is identical to calling search without --long
[
{
"name": "color",
"scope": "unscoped",
"version": "4.2.3",
"description": "Color conversion and manipulation with CSS string support",
"keywords": [
"color",
"colour",
"css"
],
"date": "2022-04-05T09:15:16.379Z",
"links": {
"npm": "https://www.npmjs.com/package/color",
"homepage": "https://github.com/Qix-/color#readme",
"repository": "https://github.com/Qix-/color",
"bugs": "https://github.com/Qix-/color/issues"
},
"publisher": {
"username": "qix",
"email": "[email protected]"
},
"maintainers": [
{
"username": "qix",
"email": "[email protected]"
}
]
}
]
Expected Behavior
I expected more information, perhaps the full output of registry search
For example
> npm search --long --json --searchlimit 1 color
[
{
"package": {
"name": "color",
"scope": "unscoped",
"version": "4.2.3",
"description": "Color conversion and manipulation with CSS string support",
"keywords": [
"color",
"colour",
"css"
],
"date": "2022-04-05T09:15:16.379Z",
"links": {
"npm": "https://www.npmjs.com/package/color",
"homepage": "https://github.com/Qix-/color#readme",
"repository": "https://github.com/Qix-/color",
"bugs": "https://github.com/Qix-/color/issues"
},
"publisher": {
"username": "qix",
"email": "[email protected]"
},
"maintainers": [
{
"username": "qix",
"email": "[email protected]"
}
]
},
"flags": {
"insecure": 0
},
"score": {
"final": 0.38903615890331245,
"detail": {
"quality": 0.5395409662759634,
"popularity": 0.4959066747321972,
"maintenance": 0.15316152246929846
}
},
"searchScore": 100000.43
}
]
Steps To Reproduce
Run the commands above. I've checked on 8.x, 9.x and 10.6.0 using nvm
It looks like the config value is never used in search.js. Compare the other referenced commands from the help docs: ls.js and help-search.js. Both access the config via this.npm.config.get('long'), but search.js only uses this.npm.flatOptions which doesn't contain the long prop.
Environment
- npm: 10.6.0
- Node.js: 20.12.2
- OS Name: ArchLinux
- System Model Name: Toaster
- npm config:
; nothing special
I recovered the "expected" behavior with only a few small changes to search.js (marked in comments)
class Search extends BaseCommand {
// ...
async exec (args) {
const opts = {
...this.npm.flatOptions,
...this.npm.flatOptions.search,
detailed: true, // NEW: request full response from search API
include: args.map(s => s.toLowerCase()).filter(s => s),
exclude: this.npm.flatOptions.search.exclude.split(/\s+/),
}
// NEW: long is not in flatOptions
const returnLong = this.npm.config.get('long');
if (opts.include.length === 0) {
throw new Error('search must be called with arguments')
}
// Used later to figure out whether we had any packages go out
let anyOutput = false
class FilterStream extends Minipass {
constructor () {
super({ objectMode: true })
console.log(opts);
}
write (pkg) {
// NEW: pkg now contains a package prop plus extra info
if (filter(pkg.package, opts.include, opts.exclude)) {
// NEW: only JSON output supports extra fields
super.write((returnLong && opts.json) ? pkg : pkg.package)
}
}
}
// ... class continues
}
This would add support for --long when using --json, but not otherwise. It would be helpful to have access to the popularity and flags.insecure props from the CLI ;)
On the other hand, it would also make loads of sense to just remove the --long flag from search altogether and update the docs appropriately.
I thing --long probably doesn't make sense anymore. It was a bandage over the real problem, which is that table output for search was not a good fit. All it ever actually did was prevent the columns from truncating, which it looks like it hasn't been doing since npm@6.
As far as adding those flags, that'd be a separate feature request. I don't thing popularity is likely to be added, but I think adding an extra line of caution if insecure is not 0 would be a great addition to the search results.
Closing this as it's not a bug, but if someone wants to submit a PR to add something if insecure is true that would probably be an easy task.
Is there an existing issue for this?
- [X] I have searched the existing issues
This issue exists in the latest npm version
- [X] I am using the latest npm
Current Behavior
This could also be a feature request or a docs update depending how you look at it...
When calling
npm searchwith the--longflag, e.g.> npm search --long --json --searchlimit 1 colorI get this output, which is identical to calling search without
--long[ { "name": "color", "scope": "unscoped", "version": "4.2.3", "description": "Color conversion and manipulation with CSS string support", "keywords": [ "color", "colour", "css" ], "date": "2022-04-05T09:15:16.379Z", "links": { "npm": "https://www.npmjs.com/package/color", "homepage": "https://github.com/Qix-/color#readme", "repository": "https://github.com/Qix-/color", "bugs": "https://github.com/Qix-/color/issues" }, "publisher": { "username": "qix", "email": "[email protected]" }, "maintainers": [ { "username": "qix", "email": "[email protected]" } ] } ]Expected Behavior
I expected more information, perhaps the full output of registry search
For example
> npm search --long --json --searchlimit 1 color[ { "package": { "name": "color", "scope": "unscoped", "version": "4.2.3", "description": "Color conversion and manipulation with CSS string support", "keywords": [ "color", "colour", "css" ], "date": "2022-04-05T09:15:16.379Z", "links": { "npm": "https://www.npmjs.com/package/color", "homepage": "https://github.com/Qix-/color#readme", "repository": "https://github.com/Qix-/color", "bugs": "https://github.com/Qix-/color/issues" }, "publisher": { "username": "qix", "email": "[email protected]" }, "maintainers": [ { "username": "qix", "email": "[email protected]" } ] }, "flags": { "insecure": 0 }, "score": { "final": 0.38903615890331245, "detail": { "quality": 0.5395409662759634, "popularity": 0.4959066747321972, "maintenance": 0.15316152246929846 } }, "searchScore": 100000.43 } ]Steps To Reproduce
Run the commands above. I've checked on 8.x, 9.x and 10.6.0 using
nvmIt looks like the config value is never used in
search.js. Compare the other referenced commands from the help docs:ls.jsandhelp-search.js. Both access the config viathis.npm.config.get('long'), butsearch.jsonly usesthis.npm.flatOptionswhich doesn't contain thelongprop.Environment
- npm: 10.6.0
- Node.js: 20.12.2
- OS Name: ArchLinux
- System Model Name: Toaster
- npm config:
; nothing special
