npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

Please provide a way to check if a name is available

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.


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.


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


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?


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

It’s fairly straightforward.


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


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:


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


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.


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


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.


I’ve forked npm-name to use an offline registry which lets you squat similar names without making a new request for each possibility. Please feel free to try it out.

To install my fork: npm i -g laggingreflex/npm-name-cli


This functionality really should have shipped at the same time as the new naming restrictions, which I was not aware of before I set up a whole repo and published a GitHub release (which can’t be elegantly deleted), only to find out the npm publish fails.

Can this feature please be prioritized a bit higher, considering this ticket has been open for over a year now?