Please provide a way to check if a name is available

website

(David Piepgrass) #1

When I wanted to publish a tool for people to check if the published version of an npm package would work properly before publishing it, I wanted to use a name like “checkpack”, but I discovered that people who are publishing their first dummy test package use very similar names - checkpack, checkpackage, testpack, packtest, packagetest, testpackage, all of these and more are squatted.

However “npm-testpack” seemed to be available - no search results on npmjs.com! So I developed my package using that name, with all unit & integration tests & documentation using that name.

But of course when I try to publish, what happens? Package name too similar to existing packages. What? Come on! It turned out I had overlooked the humble “npm-test-pack”.

So I would just like to request a feature to let us find out in advance if a name is available. Someone made a package called npm-name for doing this, but it doesn’t work - it told me npm-testpack was available.


Why not to redirect to the right package from similar name instead of showing 404 error page?
(Mark) #2

I usually just use npm info command for this. But would be nice to have a dedicated command. You’ll get 404 if the package doesnt exist.


(Kat Marchán) #3

@mark the issue @qwertie is having is that our spam filter treats certain package names as the same, such as names with or without -. So you would need to check every single combination to see if it’s available.

We’re aware of this issue but there aren’t any updates I can give anyone. It’s a thing we might fix at some point because it’s a pain, but it’s not as big a pain as the other stuff we’re prioritizing on the registry side.

If anyone’s interested, this is definitely something that could be written as a third party package: have an http client hit every single combination that would be considered equivalent, and see if any of them are available. This would only be like 20-30 requests, which would happen super fast in most cases. If you use pacote, you can even take advantage of the npm cache and other goodies like proxy support and registry awareness.

I think writing this tool client-side is the best way forward, and follow it up with an RFC to integrate it straight into the npm CLI once that proof of concept is in place.


(Steven) #4

our spam filter treats certain package names as the same

@zkat Is this logic open source? I think it would make sense to create a package that converts a string into “every single combination that would be considered equivalent” so that the npm server could use this package when validating a npm publish (this is obviously already implemented), but also the client could use this package to perform a check (the one that actually makes 30 HTTP requests).

Does that make sense?


(Kat Marchán) #5

@styfle https://blog.npmjs.org/post/168978377570/new-package-moniker-rules

It’s fairly straightforward.


(Steven) #6

@zkat I’m not sure it’s so simple :sweat_smile:

Here is my naive implementation:

function getPermuations(pkg) {
    const simple = pkg.replace(/[.-]/g, '');
    const arr = [simple];
    for (let i=0; i<simple.length; i++) {
        arr.push(replaceAt(simple, i, '.'));
    }
    for (let i=0; i<simple.length; i++) {
        arr.push(replaceAt(simple, i, '-'));
    }
    for (let i=0; i<simple.length; i++) {
        arr.push(replaceAt(simple, i, '_'));
    }
    return arr;
}

function replaceAt(str, i, c) {
    return str.slice(0,i) + c + str.slice(i);
}

This yields 30 results for getPermuations('jsonstream') but doesn’t even satisify the scenario where there are multiple dashes or dots mentioned in the blog post, for example: js-on-stream is not accounted for with my naive solution.


(Kat Marchán) #7

I mean, it… grows very quickly with package name length :sweat_smile: I should’ve thought for more than a second about the complexity.

iirc, permutations is exponentiation, and we have a set of three things: nothing, -, and .. And we need to choose pkglen - 1… so that’s 3 ** pkgstr.replace(/[-.]/g, '').length. Which, in retrospect, is a lot of combinations, and that assumes you’re not even putting several in a row. So that’s, I think that’s about 59,049 http requests for jsonstream? :sweat_smile:

Yeah, we should probably have this server-side :angel:


(Jefrey Sobreira Santos) #8

What if npmjs.com/package/js-on-stream simply redirected to npmjs.com/package/jsonstream? Like Wikipedia does.


(Matt Travi) #9

some packages exist for this, like npm-name, squatter, and validate-npm-package-name. are there gaps that aren’t covered by these? i agree that it would be nice to have first-class support, especially to get the behaviors combined into a single command, but i’ve been looking into these in the meantime.


(David Piepgrass) #10

As I mentioned travi, npm-name may falsely tell you that a name is available.


(Metaa) #11

I had a similar issue a while back where everything was using a fixed name I decided on and which actually was free - only to discover the (back then) new squatting rule that made it impossible for me to use that name.

So yeah, a native way to check if a name is legal (according to the laws of squatting) to use would be awesome.