-
Notifications
You must be signed in to change notification settings - Fork 3.4k
feat: introduce 'location' parameter for npm config command #3471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1103,6 +1103,31 @@ define('local-address', { | |
flatten, | ||
}) | ||
|
||
define('location', { | ||
default: 'user', | ||
short: 'L', | ||
type: [ | ||
'global', | ||
'user', | ||
'project', | ||
], | ||
defaultDescription: ` | ||
"user" unless \`--global\` is passed, which will also set this value to "global" | ||
`, | ||
description: ` | ||
When passed to \`npm config\` this refers to which config file to use. | ||
`, | ||
// NOTE: the flattener here deliberately does not alter the value of global | ||
// for now, this is to avoid inadvertently causing any breakage. the value of | ||
// global, however, does modify this flag. | ||
flatten (key, obj, flatOptions) { | ||
// if global is set, we override ourselves | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this log a warning? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is here just to maintain the previous behavior of |
||
if (obj.global) | ||
obj.location = 'global' | ||
Comment on lines
+1125
to
+1126
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This logic doesn't appear to be working correctly. See #3572. |
||
flatOptions.location = obj.location | ||
}, | ||
}) | ||
|
||
define('loglevel', { | ||
default: 'notice', | ||
type: [ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -64,6 +64,9 @@ Object { | |
"l": Array [ | ||
"--long", | ||
], | ||
"L": Array [ | ||
"--location", | ||
], | ||
"local": Array [ | ||
"--no-global", | ||
], | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
built-in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
leaving that out was intentional, feels like the built-in use case should be a file overwritten by packagers and not something a user would interactively change on their own to me. I'm definitely open to discuss it though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d expect it to be undocumented regardless, but it seems pretty useful for debugging the source of an unexpected default config (for “get”), and it seems weird to allow it for get and not for set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get
andlist
both ignore the parameter entirely. they aren't location specific, they return whatever the most prioritized value(s) is/are. we could allow for the location flag on them as a means of saying "show me only data from this location" in which case I agree exposing built-in would be appropriate. if we did that, though, we would have to remove the default value for the location and have separate behaviors in the commands for a value ofnull
which i don't love...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah hm, that's a fair point.
if it's only going to work in
set
then omitting built-in makes sense; but it seems more useful to me if it works for all of get/list/set, and includes built-in.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to address the issue of debugging the source of an unexpected config value, how about we allow
npm config list
to accept config keys for which it will list everywhere that key is defined and what overwrote what.so
npm config get key
will continue to return a single value representing the value ofkey
from its highest prioritized source, andnpm config list -l key
will list every value thatkey
has in any source in a way that makes it clear why it was overridden from other sources.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For list, that sounds great.