--registry argument should override package.json#publishConfig.registry

(Alan) #1

Refer to: https://github.com/npm/npm/issues/5522

What I Wanted to Do

–registry CLI argument overrides package.json publishConfig.registry

What Happened Instead

package.json publishConfig.registry overrides --registry CLI argument

Reproduction Steps

Refer to: https://github.com/npm/npm/issues/5522


Refer to: https://github.com/npm/npm/issues/5522


(Alan) #2

this is arguably a “bug”, not an “idea”


(Alan) #3

has anybody looked into this?


(John Gee) #4

Probably no one has looked into it since the linked bug was closed, it was not a high priority for the core team at the time, and no offers of a patch from others, and was originally reported in 2014.


(John Gee) #5

If you meant had anyone looked at this report, it got less visibility because it was under #ideas, and didn’t ask a question.

You could report it or refile it under #bugs using the bugs template (which it looks like you were following). You can edit the category by editing the title.


(Lars Willighagen) #6

The post was moved from #bugs to #ideas because it isn’t necessarily a bug. It is, however, a good idea.


(Alan) #7

to call this an “idea” vs a “bug” would go counter to the enormous claim in the comments section of the GitHub issue where the majority see it as a bug


(Stedman98) #8

i agree - very glitched

1 Like

(Lars Willighagen) #9

Quoting an actual maintainer in that very post (in fact the only one from npm who commented on it):

It’s not a bug, because the current behavior is more or less underspecified and the current behavior is at least reasonable, if not what many users expect. Changing it at this point is actually a semver-major change, because it changes how the CLI handles this piece of configuration.

Again, I agree that --registry overriding publishConfig.registry makes a lot of sense, but that’s not the specified, nor the intended behavior, and therefore it isn’t a bug. It is a great feature request, and I agree it should be implemented, but that doesn’t make the current behavior a bug.


(Alan) #10

@larsgw that is a very weak response to claiming it is not a bug, saying that “the intended behaviour is not specified therefore not a strong enough argument for it being a bug” is pretty much putting lipstick on a pig, the community democratically agrees it is a bug, but the maintainers (minority) think it’s not … you do the math … the scales are clearly tipping in favour of this being a bug “but we won’t classify it as such because … reasons” … saying this is not a bug only angers people


(John Gee) #11

Apologies @larsgw, I missed that the topic had been moved from #bugs originally.
[edit] Apologies to @alan-czajkowski too.


I understand that you consider it a bug. It is frustrating when software does not work the way you think it should. Do you have any new information or insights to offer that wasn’t in the link?

Note that people who would like this behaviour changed can vote on this topic to increase its weight, as one person already has. (The button up the top.) This is true whether it it is under #ideas or #bugs. I see it is now under #bugs.

A very knowledgeable person who contributes a huge amount to the community and contributes lots of code changes has said it is a “great feature”. In many ways that is more likely to get the behaviour changed than whether we call it a bug or a feature.

1 Like

(Alan) #12

@shadowspawn I originally submitted it, I believe as a “bug”, it was then switched to “idea”, and then I recently switched it back to “bug”