5 ms·

Please don't think this way. This is such a solvable problem. Doesn't package.json have an is private repo flag? Why not just respect that? Why does everyone

by lugg 8y ago

Please don't think this way. This is such a solvable problem. Doesn't package.json have an is private repo flag? Why not just respect that? Why does everyone everyone in this thread think a pop up is the solution? Pop ups are a code smell. They mean your application does not correctly match user intent with the action so badly you had to specifically get your user to tell you what they meant to do. Did you mean to do that? Always, yes. Otherwise, undo. The only place did you mean makes sense is in Google search results. Why is public and private publish anywhere near each other? Why are they even on the same page? Stop drawing boundaries around nouns.

kall 8y ago
npm publish already prevents you from publishing a package that has the private flag. They must not have had it set.
alexanderdmitri 8y ago
I disagree, there have been times a well-placed popup stopped me from accidentally doing something really stupid, other times there wasn't a popup and I ended up doing something stupid. It doesn't necessarily have to be a pop up popup per say, but extra validation around dangerous actions is user friendly. And of course there can always be an override for the extra validation in case it potentially screws up some people's workflows, but I'd make a user explicitly set the override, like the 'NoHostAuthenticationForLocalhost' option in ssh for example.
- gowld 8y ago
  Popups only work if they Confirm button is not a button, but "enter this text exactly: I really want to publish this package to the whole wide world" and block copy-paste. If the user hacks around that, it's their own fault.
- lugg 8y ago
  If a pop up is required to prevent you doing something stupid the UX has already failed. I don't think a popup solving a problem means it is solving the right problem in the right way.
madeofpalk 8y ago
> Doesn't package.json have an is private repo flag? Why not just respect that? npm does reflect that flag. If you set private in package.json, npm won't publish it publicly. From docs: > private > If you set "private": true in your package.json, then npm will refuse to publish it. > This is a way to prevent accidental publication of private repositories. If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the publishConfig dictionary described below to override the registry config param at publish-time.
- bigiain 8y ago
  Perhaps inverting the logic there might be worth considering? Make it so you have to explicitly go in and mark your package.json as public before npm will publish it, and have the default be private? I don't have _too_ much sympathy for the bank here - it's in npm's best interest to make it easy to publish leftpad.js easily <snarky smirk> - and that probably should be their default stance. The bank should be responsible for ensuring their "banking grade security" includes not accidentally publishing their source code to public repos. (How much would you bet against there being instances exactly like this where the publication vector was GitHub instead of npm? How much would you bet against this exact code being on a public git repo somewhere as well? How many public code hosting services should be expected to change their business models because some bank gets uptight after they've fucked up?)
  - BoorishBears 8y ago
    What's impressive to me is you (and so many others) being charitable enough to assume that the original developer didn't intentionally publish this package. Some bank developer (or more likely, some underpaid contractor) wants to share something between projects and doesn't want the hassle of proper channels, or just doesn't care enough and thinks "I'll publish this, who will ever find it?". Years later someone stumbles upon it, maybe they don't even know who did it, "NPM why do you have our code?!?!?!?!" This is the most likely scenario once you consider this was a bank. In which case there's nothing NPM could do. No warning would have changed their intent, they knew what they were signing up for.
eklavya 8y ago
> Pop ups are a code smell. They mean your application does not correctly match user intent with the action so badly you had to specifically get your user to tell you what they meant to do. Not a rule. Do you really want undoable actions like "Delete" to just delete in a touch operated interface?
kbenson 8y ago
I wasn't condoning popups. I was making a high level observation of package systems in general. That said, I fully support a terminal level confirmation the first time something is pushed publicly in any package manager. It is absolutely the correct thing to do to add safeties to a process that is irreversible and can have negative consequences. Often enough, making anything public online is irreversible, and making something public that wasn't ever supposed to be can have negative consequences in many respects. But what I was really thinking of when I was typing my original comment was moving to a system where someone actually approves new package publishing accounts and or some subset of package namespace requests. Systems that start without any sort of moderating or approval process seem to eventually settle on one. The reasons for this are numerous, from security to just keeping people from overwhelming the more common or sought after names and general sanity checks (does a system really need to allow separate packages for a term where one is singular and one is plural? Who does that help?).

by lugg 8y ago

kall 8y ago

npm publish already prevents you from publishing a package that has the private flag. They must not have had it set.

alexanderdmitri 8y ago

I disagree, there have been times a well-placed popup stopped me from accidentally doing something really stupid, other times there wasn't a popup and I ended up doing something stupid. It doesn't necessarily have to be a pop up popup per say, but extra validation around dangerous actions is user friendly. And of course there can always be an override for the extra validation in case it potentially screws up some people's workflows, but I'd make a user explicitly set the override, like the 'NoHostAuthenticationForLocalhost' option in ssh for example.

gowld 8y ago
Popups only work if they Confirm button is not a button, but "enter this text exactly: I really want to publish this package to the whole wide world" and block copy-paste. If the user hacks around that, it's their own fault.
lugg 8y ago
If a pop up is required to prevent you doing something stupid the UX has already failed. I don't think a popup solving a problem means it is solving the right problem in the right way.

madeofpalk 8y ago

> Doesn't package.json have an is private repo flag? Why not just respect that? npm does reflect that flag. If you set private in package.json, npm won't publish it publicly. From docs: > private > If you set "private": true in your package.json, then npm will refuse to publish it. > This is a way to prevent accidental publication of private repositories. If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the publishConfig dictionary described below to override the registry config param at publish-time.

bigiain 8y ago
Perhaps inverting the logic there might be worth considering? Make it so you have to explicitly go in and mark your package.json as public before npm will publish it, and have the default be private? I don't have _too_ much sympathy for the bank here - it's in npm's best interest to make it easy to publish leftpad.js easily <snarky smirk> - and that probably should be their default stance. The bank should be responsible for ensuring their "banking grade security" includes not accidentally publishing their source code to public repos. (How much would you bet against there being instances exactly like this where the publication vector was GitHub instead of npm? How much would you bet against this exact code being on a public git repo somewhere as well? How many public code hosting services should be expected to change their business models because some bank gets uptight after they've fucked up?)
- BoorishBears 8y ago
  What's impressive to me is you (and so many others) being charitable enough to assume that the original developer didn't intentionally publish this package. Some bank developer (or more likely, some underpaid contractor) wants to share something between projects and doesn't want the hassle of proper channels, or just doesn't care enough and thinks "I'll publish this, who will ever find it?". Years later someone stumbles upon it, maybe they don't even know who did it, "NPM why do you have our code?!?!?!?!" This is the most likely scenario once you consider this was a bank. In which case there's nothing NPM could do. No warning would have changed their intent, they knew what they were signing up for.

eklavya 8y ago

> Pop ups are a code smell. They mean your application does not correctly match user intent with the action so badly you had to specifically get your user to tell you what they meant to do. Not a rule. Do you really want undoable actions like "Delete" to just delete in a touch operated interface?

kbenson 8y ago

I wasn't condoning popups. I was making a high level observation of package systems in general. That said, I fully support a terminal level confirmation the first time something is pushed publicly in any package manager. It is absolutely the correct thing to do to add safeties to a process that is irreversible and can have negative consequences. Often enough, making anything public online is irreversible, and making something public that wasn't ever supposed to be can have negative consequences in many respects. But what I was really thinking of when I was typing my original comment was moving to a system where someone actually approves new package publishing accounts and or some subset of package namespace requests. Systems that start without any sort of moderating or approval process seem to eventually settle on one. The reasons for this are numerous, from security to just keeping people from overwhelming the more common or sought after names and general sanity checks (does a system really need to allow separate packages for a term where one is singular and one is plural? Who does that help?).