I find myself using the npm website a lot instead of this CLI. And when I thought about why, I realized it is because squatting is a common problem that is not taken into account here. Often a name is not technically available but only because someone is squatting on the namespace. On the website, I can see whether it is worth trying to acquire the name, but on the command line I have no way of knowing.

What do you think about incorporating something that would offer that kind of feedback into npm-name?

My thinking is that it should still exit non-zero but display a warning instead of an error:

⚠ foo is squatted

I wanted to explore how that would work, so I built a squatting detector. Hope it is useful either way.

@sindresorhus - Is there something else I need to install globally to take advantage of this tool?

It's complaining about const.

const logSymbols = require('log-symbols');
^^^^^
SyntaxError: Use of const in strict mode.

I tried modifying the hashbang temporarily in cli.js:

#!/usr/bin/env node --harmony

... but then it got stuck up on the template string.

Thanks for the insight.

I have been using this tool for couple of weeks.
This is the first time I am getting this error, and its throwing only for this package name n-mysql

Command
npm-name n-mysql

Error

Hello,

what's the purpose of this library? 😀
You can do the same without having any dependency on Node and npm at all:

curl -L -s -o /dev/null -w "%{http_code}" "https://npmjs.org/package/PUT-PACKAGE-NAME-HERE"

If it prints 404, the package doesn't exist.

You can even define a command in your .bashrc (or whatever shell you use):

# in .bashrc
npkg() {
  curl -L -s -o /dev/null -w "%{http_code}" "https://npmjs.org/package/$1"
  echo
}

# in shell
$ npkg somenonexistingpackage
404 # Package doesn't exist
$ npkg babel
200 # Package exists!

The link should be to https://www.npmjs.com/org/babel instead.

» npm-name --version
2.6.0

When check multiple names and an error happening, the output is just error and all other useful results are missed.
So can we handle the errors more friendly ? Maybe hint and skip the error name and then check the latter names continuously ?

I had try to publish on npm package named 'while-true'. npm answered me:

npm ERR! publish Failed PUT 403
npm ERR! code E403
npm ERR! Package name too similar to existing packages; try renaming your package to '@astur/while-true' and publishing with 'npm publish --access=public' instead : while-true

And it was first moment when I found that something wrong with name 'while-true'. This name is reported by npm-name as available:

~ $ npm-name while-true
✔ while-true is available

It will be better if npm-name will say something like this:

⚠ while-true is free but available

...or like this:

⚠ while-true is too similar to existing package whiletrue

• npm-name-cli v4.0.1
• node v12.16.3
• npm v 6.14.4

Throws error:
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: [MY_HOME_FOLDER]/.nvm/versions/node/v12.16.3/lib/node_modules/npm-name-cli/cli.js

Hi, I just tried out this tool and I realized that it tells you if the provided package name exists on NPM but not if it is actually available to publish on NPM . Because of the similarity between the provided package name and one(s) already existing, that name could be rejected when publishing even if npm-name-cli tells us it is available

HTTPError throws when checking some package names via this cli-package. Like this:

~ $ npm-name f
HTTPError: Response code 404 (Not Found)
    at stream.catch.then.data (/usr/local/lib/node_modules/npm-name-cli/node_modules/squatter/node_modules/got/index.js:182:13)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

f is real npm package.

When using API from npm-name it will be all right for this package:

const nn = require('npm-name');
await nn('f') // false

I thing it is a bug.

Seems like this is no longer faster than npm search:

❯ time npm search unicorn-cats
No matches found for "unicorn-cats"
npm search unicorn-cats  0.84s user 0.29s system 64% cpu 1.768 total

❯ time npm-name unicorn-cats
⠋ Checking name on npmjs.com…^C
npm-name unicorn-cats  24.16s user 3.55s system 27% cpu 1:39.20 total

I gave it 30 seconds before giving up. Possibly related: is-name-taken (sindresorhus/np#592)

Context

Hey @sindresorhus thank you for the lib!

I was trying to use trough npx and sadly found out that the module can not be run by it since it is and ES module.

Reproducing

When I run it I get the flowing error

npx npm-name-cli @fluid

npx: installed 286 in 33.964s
Cannot use import statement outside a module
(node:3732) Warning: require() of ES modules is not supported.
require() of /home/rpt/.npm/_npx/3732/lib/node_modules/npm-name-cli/cli.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename cli.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /home/rpt/.npm/_npx/3732/lib/node_modules/npm-name-cli/package.json.

Versions

I'm using node 12.14 and npm 6.13.4 on arch and zsh to reproduce it.

I guess the module version is the latest in npx, which to me seems to be 4.0.1.

Suggestions

From the error I'm guessing it could be done by simply changing the cli file extension from .js to .cjs, but I'm not that familiar with this kind of issue.

I'm willing to help and even try to open a PR if you are open to it.

Thank again for the amazing OSS you do!

I think an (optional?) thesaurus of names relating to the search could be useful.

Is this something others are interested in?

e.g. npm-name -t breakdance could give:

• freakout is avaliable
• harlem-shake is avaliable

Hello, Sindre

I am working on a tool I call Visual CLI, which presents a lot more user friendly (graphical) interface to (initially) Aurelia CLI. This tool is implemented as an Electron app and in addition to the standard set of services, like code generation based on user's input, it will assist with interactions with npm - like:

I was using the npm API for the above prototype and even tried some local npm database caching for better responsiveness. I liked your comments / answers to your own question on why to use npm-name-cli

Nicer & simpler output

npm search is only supported on npm 4, which is only bundled with Node.js 7.4+

Squatter detection

Performance

so, I thought it might make sense to have you see this note and hopefully get me your feedback.

Here's the error I got when I tried to run the command on Node 14:

file:///Users/alflennik/.nvm/versions/node/v14.5.0/lib/node_modules/npm-name-cli/node_modules/npm-name/index.js:10
import {isTaken} from 'is-name-taken';
        ^^^^^^^
SyntaxError: The requested module 'is-name-taken' is expected to be of type CommonJS, which does not support named exports. CommonJS modules can be imported by importing the default export.
For example:
import pkg from 'is-name-taken';
const {isTaken} = pkg;
    at ModuleJob._instantiate (internal/modules/esm/module_job.js:98:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:137:5)
    at async Loader.import (internal/modules/esm/loader.js:162:24)

I reverted to Node 12 and it worked.

Thanks for the package, by the way! It helped me find a great package name.

recently the npm registry was updated to restrict available pkg names based on the presence of a pkg with a similar name whose diff is only punctuation. this is an awesome tool that helps people find pkg names, i'd like to make a PR to help account for this new registry restriction. if welcome, PR incoming.

for more details on the change, see this blog post: http://blog.npmjs.org/post/168978377570/new-package-moniker-rules

~ $ npm-name _AVA
✔ _AVA is available

But such names are invalid. It will be better if npm-name will say something like this:

✖ _AVA is invalid

When checking estar the output is the following:

prantlf@macik:~ npm-name estar
Error: Package `estar` doesn't exist
    at /Users/prantlf/.nvm/versions/node/v14.17.0/lib/node_modules/npm-name-cli/node_modules/package-json/index.js:62:11
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async squatter (/Users/prantlf/.nvm/versions/node/v14.17.0/lib/node_modules/npm-name-cli/node_modules/squatter/index.js:39:18)
    at async file:///Users/prantlf/.nvm/versions/node/v14.17.0/lib/node_modules/npm-name-cli/utilities.js:16:29
    at async Promise.all (index 0)
    at async checkNames (file:///Users/prantlf/.nvm/versions/node/v14.17.0/lib/node_modules/npm-name-cli/utilities.js:12:16)
    at async file:///Users/prantlf/.nvm/versions/node/v14.17.0/lib/node_modules/npm-name-cli/cli.js:79:19

Saying "Package estar doesn't exist" is wrong, because although there is no package with the name estar, the existing package es-tar will prevent the name estar from being used by another package.