Hacker News Reader

Comment by madeofpalk | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com