The owner of several 1 letter NPM packages(npmjs.com)
npmjs.com
The owner of several 1 letter NPM packages
https://www.npmjs.com/~zhengzk
35 comments
Good news! npm's dispute policy actually explicitly covers this behaviour. If someone wanted any of these packages, npm would likely be happy to give it to them. You can also report them to have the packages removed by emailing them at [email protected]
Source: https://www.npmjs.com/policies/disputes
Source: https://www.npmjs.com/policies/disputes
Interesting, I had no idea. Thanks!
I didn't know about this. Perhaps it should be better publicised?
It's right in the footer with a clear name in all NPM's pages... it took me no time when I was looking for it back in the day to find the policy, maybe the problem is you never needed it?
You're referring to a link buried within 'Legal Stuff' at the bottom of the page, away from all other actionable sections linked to a package.
I don't think that's even close to being a satisfactory call-to-action.
Whenever I've picked a name for a project, I've always generated them by combining words together with hyphens. If I realised that I could take over package names that were being squatted, there are many times I would have done so.
I don't think that's even close to being a satisfactory call-to-action.
Whenever I've picked a name for a project, I've always generated them by combining words together with hyphens. If I realised that I could take over package names that were being squatted, there are many times I would have done so.
Yes? I mean the one clearly labeled "Package Name Disputes"... it's not like this page needs a big CTA, it's something you'd reasonably expect to find within a "Policy" or "Terms of Service" page but instead it has a link on every footer.
And actually... "Package name disputes" are mentioned in different ways within 5 of the 6 links in the "Legal stuff" section, so I am pretty sure that it's just for lack of reading/searching, not because they are actively trying to hide it.
And actually... "Package name disputes" are mentioned in different ways within 5 of the 6 links in the "Legal stuff" section, so I am pretty sure that it's just for lack of reading/searching, not because they are actively trying to hide it.
If a package has only one published version with no dependents or real users, the call-to-action should be a button near the top of the screen that should describe the action expected (e.g. "claim package name").
Clicking on this button should start a partly-automated, formal process and not require writing an email or manually soliciting contact with the original owner. This process can then be managed by NPM, who can stop relying on hearsay over whether these disputes are being resolved.
The only reason to bury this within the 'Legal Stuff' section is when you erroneously assume that this action is likely to be a legal issue and informed by patent, trademark or copyright law.
The current solution is cumbersome, not pointed to sufficiently, and likely to become progressively worse as the NPM ecosystem expands. I'd bet many NPM users aren't familiar with this resolution process. (Apart from those that remember the kik and left-pad debacles. "hahah, you’re actually being a dick. so, fuck you. don’t e-mail me back.")
All I'm saying is that this process needs to be clear, structured and measurable.
If NPM was doing a good job here, this HN post would never have been upvoted.
Clicking on this button should start a partly-automated, formal process and not require writing an email or manually soliciting contact with the original owner. This process can then be managed by NPM, who can stop relying on hearsay over whether these disputes are being resolved.
The only reason to bury this within the 'Legal Stuff' section is when you erroneously assume that this action is likely to be a legal issue and informed by patent, trademark or copyright law.
The current solution is cumbersome, not pointed to sufficiently, and likely to become progressively worse as the NPM ecosystem expands. I'd bet many NPM users aren't familiar with this resolution process. (Apart from those that remember the kik and left-pad debacles. "hahah, you’re actually being a dick. so, fuck you. don’t e-mail me back.")
All I'm saying is that this process needs to be clear, structured and measurable.
If NPM was doing a good job here, this HN post would never have been upvoted.
I agree with that, it could be improved and automatically detect abusers.
NPM is also improving, AFAIK they were really messy in the beginning and now getting better and better. This issue came up as I mentioned in other places because of an initial error that has been corrected long ago (case-sensitive package names). So hopefully someone will see your comment and do something about it.
NPM is also improving, AFAIK they were really messy in the beginning and now getting better and better. This issue came up as I mentioned in other places because of an initial error that has been corrected long ago (case-sensitive package names). So hopefully someone will see your comment and do something about it.
How would you like us to better publicize it? I agree it's a few clicks away from the home page, but as others have noted not a lot of people need to enter this process, so giving it prominence on e.g. every package page would be overkill.
Even better, packages should be namespaced to the parties maintaining them
This has been supported for a long while now but it never really caught on much. It's still an option if your favourite name is taken, though.
Is this the @a/b namespacing that requires paying monthly for names (that are longer)? That’s not going to fly for most people.
Scoped packages are free: https://docs.npmjs.com/getting-started/scoped-packages
In regards to length, well, that's how namespacing works. Although that is likely part of what has contributed to it receiving less traction.
In regards to length, well, that's how namespacing works. Although that is likely part of what has contributed to it receiving less traction.
Oh, I thought you needed to register an organization to use scoped packages. Thanks! (And yes, I don't mind the length... unless I'm paying for it.)
[deleted]
That's just shuffling the problem around, people will squat on user accounts.
Empirically, it doesn't just shuffle the problem around, it dramatically reduces it. On Google Code, every time you tried to create a project, the name would always be taken. On Github, every time you try to create a project, you can go ahead and use the name, and I haven't heard of anyone having trouble finding something acceptable to use for their account name.
I also was able to do this for my startup https://github.com/commando from GitHub. @commando was being squatted, but after they researched and I proved I was the owner, they transferred the organization name to me. +1 for GitHub.
A few points: as @chrisfosterelli noted, if a package is being squatted we'll give it to you, no problem.
As for why we don't automatically/proactively handle squatting: it's a very thorny problem. Whatever minimum standard we applied to count as "not squatting" could be trivially discovered and gamed, eventually resulting in people who wanted to squat on a name just publishing a copy of `express` or something to that name as a placeholder.
Relatedly: you can report offensive, or deliberately confusing package names ("typosquatting") and we will take those package names down permanently.
As for why we don't automatically/proactively handle squatting: it's a very thorny problem. Whatever minimum standard we applied to count as "not squatting" could be trivially discovered and gamed, eventually resulting in people who wanted to squat on a name just publishing a copy of `express` or something to that name as a placeholder.
Relatedly: you can report offensive, or deliberately confusing package names ("typosquatting") and we will take those package names down permanently.
This account is clearly squatting. Not only do they hold several one letter package names but also many other names that are generic. The majority of them have nothing more than a package.json
A new version of website squatting? There can't be very much money in npm package squatting, though.
A fellow poster up a bit mentioned that the empty 'D' package has something like 64k downloads per day. Surely there's money in compromising the systems that this ends up on? Malicious packages are a known point of vulnerability, and with that broad a shot, you're likely to get access to at least a few apps / AWS accounts / whatever.
[deleted]
https://www.npmjs.com/package/D
Shouldn't NPM be able to determine the difference between packages that are in use and package squatting?
Stats
64,840 downloads in the last day
1,360,036 downloads in the last week
4,980,362 downloads in the last month
Shouldn't NPM be able to determine the difference between packages that are in use and package squatting?
It looks like npm is confusing the download count with another package, 'd' (lowercase)[0]. I didn't realize that npm packages were case-sensitive, and apparently neither does their download counter!
Edit: Apparently there is a Github issue for this[1]
[0]: https://www.npmjs.com/package/d [1]: https://github.com/npm/registry/issues/38
Edit: Apparently there is a Github issue for this[1]
[0]: https://www.npmjs.com/package/d [1]: https://github.com/npm/registry/issues/38
And I think they aren't anymore. But they were back in the day, so for compatibility reasons they have to keep some of them that way.
Edit: further evidence: when you mistype a name in lowercase such as https://www.npmjs.com/package/aaaaaaaaaabbb it gives you instructions on how to create the package with that name; however when you do with a name with a capital letter such as https://www.npmjs.com/package/aaaaaaaaaabbB it just shows a 404
Edit: further evidence: when you mistype a name in lowercase such as https://www.npmjs.com/package/aaaaaaaaaabbb it gives you instructions on how to create the package with that name; however when you do with a name with a capital letter such as https://www.npmjs.com/package/aaaaaaaaaabbB it just shows a 404
Ah, that makes sense. Given that OSX and Windows are often case insensitive filesystems I could see that being a world of messy edge cases.
Possibly missing a hyphen when issuing `npm install -D <something>`
Sure, guy looks like a jerk, but these are terrible package names, I'm glad no libraries I use have these names.
Google searches would be so bad.
Google searches would be so bad.
Only one I can think of that's useful is the q promise library. `npm install q`
Agreed, single letter library names are essentially useless. Some of the others, however, maybe not. Overall I'd like to see a policy against squatting on a specific library name and never using it.
But there is one right in the footer: https://www.npmjs.com/policies/disputes
I am writing a blog post about the topic as well, I think NPM is doing a great job here.
I am writing a blog post about the topic as well, I think NPM is doing a great job here.
I had no idea. I never heard of npm doing this and missed it as a spot on the site. Thanks!
[deleted]
For example I contacted GitHub because I wanted an organization name for a company I'm registering in 2017. Their support looked at the organization, which had zero public or private repositories, told me they went beyond a time period of zero activity in which their name could be reclaimed by someone else and I got it (and no they didn't tell me the time period, it was just a vague statement regarding it).
NPM should look at these and if they've been empty for X amount of time, remove them. Now the problem is controlling new squatters so they may need to offer a more complex solution when a name returns to the pool but I think it needs to be done (I know names don't typically return to be re-used in NPM but if they're removing them for squatting I think they should).