Hacker News Reader

Comment by kbenson | Hacker News Reader

At some points in a language and its package management system's lifetime, reducing barriers to publishing are one of the best things that can be done to increase packages and fill out the ecosystem, and drive utility and adoption.

Later, once you have most needs filled by packages, and a good number of enterprise users, more control is beneficial. Companies appreciate it, and single users are willing to jump through an extra hoop or two much of the time because the rest of the ecosystem is so useful that it's not worth switching languages.

I think it's unlikely that a system will move from one style to another without an event causing them to reevaluate their prior choices. More likely, multiple events. This has already happened with NPM for other choices they made in the past, such as letting package namespaces be claimed by new people after someone gives it up, and whether releases are immutable, IIRC.

View on HN

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.

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

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.

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.

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.

> 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.

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?)

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.

If there’s enough friction, no one would bother publishing to public repo instead of setting up private Nexus instance, which is quite easy. And it’s quite possible that the leak could happen on early stage of CI setup for that project (private flag removed, but wrong login used). It’s a mistake very easy to make: “private” flag is just not an appropriate tool for private CI.

I think open source tools should always default to sharing. If you're trying to keep things secret it should be up to you to keep them secret.

> it's in npm's best interest to make it easy to publish leftpad.js easily

That's what I was getting at above. It definitely was in NPM's best interest to do so. Depending on your definition of "easily", is it still in their interest to have it quite that easy? Perhaps a different default is in order now, as you suggest. Or perhaps it should even require a confirmation dialog on the terminal for the first public push? People will still use NPM at this point. Not having enough packages or a package for a specific functionality is hardly a problem for them any more.

They could just change it to `npm publish npm|url name` with some useful warnings. The name should be checked against package.name.

Then libraries could simply add an npm script for publishing.

    npm publish

    To publish a package to
    npm, you must enter:

      npm publish npm <package-name>

    To publish a package to
    another registry, you
    must enter:

      npm publish <url> <package-name>

Just as easy, just clearer.

cool, so now the developer that did this will just thoughtlessly type npm publish npm instead.

At the end of the day, there's only so much you can do. Really, a hammer shouldn't have a prompt on it confirming each hit. If it does, users will just instinctively press it and then a few months down the road they'll hit their thumb.

The npm docs also state that the "files" property of the package.json limits what gets installed if you install that package in another project.

Ever tried installing a local package via a file path? NPM just symlinks it into node_modules, causing issues because you suddenly have duplicated dependencies. Yarn does the same, btw.

I have given up any hope regarding npm/yarn acting sensible long ago.

>publishConfig

https://github.com/yarnpkg/yarn/issues/5310

oops

> 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?

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?).

This is going to be cynical, but as far as I understand it people are looking for usability through vanity.

Why not install `com.facebook.react’? Reverse domain notation is remarkably elegant given our internet. You are not typing ‘npm i com.facebook.react’ so often that it’s a pain. You probably use ‘create-react-app’ which is even worse.

Instead, every language creates a new cash grab for common names. And made it worse. New namespaces, new squatting. I can publish ‘react-racket’ and do whatever I want behind the scenes with it.

Case in point: do you add coffeescript or coffee-script.

Why optimise for keystrokes in your term instead of stability for your client? Jesus fuck.

There's a little bit of movement happening in that direction in the npm world with scoped packages. E.g. babel moving all official packages to @babel. Storybook does it too. Doesn't even have to be much of a branding loss. FB could publish @react/react, @react/native, @react/eslint-config, @react/create-app, @react/prop-types, @react/dom... Most of the typing is happening in require/import not npm install, so there's some argument for not going the full java route.

The JavaScript community is moving into the Enterprise and is discovering Java's good ideas from 1995

Excellent.

A whole quarter of a century, or perhaps half of the entire software industries lifetime, of exciting known security errors to look forward to!

BRB, off to hide all my bitcoin under my mattress...

> Why not install `com.facebook.react’?

That would be a bad idea, and it's not just brevity.

- If com.facebook.hr has previously been published, would it mean that facebook can never have a division named HR?

- Once a company goes belly up, the domain often ends up with squatters/spammers. Domains with published packages will sell for a lot more in the underground market - for pure exploitation of rights to publish a newer version.

- In the absence of validation, nothing stops anyone from publishing com.google.exploitlib. And domain validation is friction.

- Most publishers on npm may not have a domain.

And finally like someone mentioned below, npm already supports scoped packages. https://docs.npmjs.com/about-scopes

Regarding your concerns, some friction is necessary. Without friction I can skate, but I can't drive.

Reply on news.ycombinator.com