Option to disable 2FA

[wessberg]

Description

With np v5.0.0, 2FA is enabled by default for new packages. However, no option is exposed to disable 2FA.

Lines 198-204 in np/index.js enables 2FA if the package doesn't exist in the registry and if it isn't private.

2FA is definitely the right default, and I encourage everyone to use it. The thing is, np comes with a lot of great defaults, but it also comes with ways of opting out of them. For example:

--no-cleanup --no-tests --yolo --no-publish --no-yarn --no-release-draft

In the same vein, something like --no-2fa should be possible. Currently it feels like the odd omission from what is otherwise a quite flexible configuration.

Possible implementation

I suggest exposing a --no-2fa CLI argument that avoids forcing 2FA for new packages.

[mikehardy]

In my case it is somehow not detecting that my package already exists, and is public. So it actually publishes but then blows before it can push tags or open the release draft. Odd error handling

[itaisteinherz]

@mikehardy Can you you open a separate issue detailing the specific problem you're experiencing?

[mikehardy]

Sure thing - will be a couple days though, I lost the output on the last release I made, which would have made an ideal case, but I release that module every couple days

[mikehardy]

opened fresh issue as instructed #427 - would be nice to be able to disable 2FA so I could push through, thus my interest in this issue

[verekia]

An other use case is for packages that are published by different people, who cannot use 2FA. Yes it is possible to publish it first with npm publish and then use np, but an option would be nice :)

[Albert-Gao]

The current workaround is np --no-publish && npm publish

[romaricpascal]

I think I've got np to bypass it with this .np-config.js file:

module.exports = {
  // Avoids `np` trying to set 2FA again and again
  // after publishing to NPM
  exists: true
}

Without that, the 2FA gets triggered, but with it nope. Hopefully:

• it actually does what I think it does
• it doesn't have other side effects

[rstacruz]

Another workaround: To stop np from trying to enable 2FA, set a registry in the publishConfig... even if it's the default npm registry.

/* package.json */
{
  "publishConfig": {
    "registry": "https://registry.npmjs.org/"
  }
}

Context: I also tried to use np on an existing package with a scoped name (eg, @rstacruz/package-name). Like the other commenters here, np somehow fails to know that the package already exists.

[pixelastic]

I create a PR to add the --no-2fa option to the cli here: https://github.com/sindresorhus/np/pull/515

[fregante]

For example, in my case, the lifetime of OTPs is shorter than required for publishing all the packages in my company's monorepo using Lerna

Why are you using lerna and np? Doesn't sound like a good use case.

An other use case is for packages that are published by different people, who cannot use 2FA.

This sounds incorrect. Every member who has access can also use 2FA.

Also 2FA is already bypassable by using tokens — if your npm publish usage is advanced — so there's little reason to disable it.

---

I think the reasoning behind disabling 2FA is just that it's an extra step, but IMHO non-default tools like np can be opinionated enough to enforce 2FA on the its users.

The whole community benefits from 2FA; use it.

I also find it annoying, but as a user I feel safer if the packages I use are published only with 2FA.

[wessberg]

@fregante

Why are you using lerna and np? Doesn't sound like a good use case.

I'm not combing those, no. But the company I work at is using Lerna. I might be using np for some of my personal projects. Activating 2FA is an account-wide change, so if you use the same npm account for contributing to an organization (such as the company you work for), you might be requested to provide OTPs when you publish a package in that organization.

The whole community benefits from 2FA; use it.

I agree. Absolutely. But there are circumstances in which a developer may want an escape hatch, and np is very much built up with a bunch of opiniated defaults, most of which come with escape hatches.

I think the reasoning behind disabling 2FA is just that it's an extra step, but IMHO non-default tools like np can be opinionated enough to enforce 2FA on the its users.

I can only answer for myself, and to me it has nothing to do with wanting to avoid an extra step. I would love to be able to always use 2FA.

I tend to agree about your point about tools like np being able to be opiniated enough to enforce certain constraints. However, I don't think that aligns with the current philosophy of np in terms of how it treats all other options. Here's some of them:

--no-cleanup --no-tests --yolo --no-publish --no-yarn --no-release-draft

Now, np could decide to be more opiniated in general, but as it stands, it has set of opiniated defaults with escape hatches. I don't see how 2FA is any different, but I welcome your perspective - and agree that 2FA is the right default, absolutely.

[fregante]

Activating 2FA is an account-wide chang

Doesn't sound right either:

As a matter of fact, some of my old packages don't have 2FA enabled.

it has set of opiniated defaults with escape hatches

You're right about this, I just don't see a valid use case listed in this thread so I default to "we don't want to bother with 2FA"

[wessberg]

Activating 2FA is an account-wide chang

Doesn't sound right either:

What you're showing here is the per-package settings which states that, if the package requires 2FA, then 2FA is strictly required for anyone attempting to publish new versions of that package. That means that if someone who haven't activated 2FA in their NPM account attempts to publish that package, it will be rejected and they will have to setup 2FA for their NPM account.

Now, activating 2FA on your account, however, means that you will always be prompted for OTPs when you publish any package - if you select "Authorization and publishing" as your 2FA mode, whether that package requires 2FA or not for publishing. So even though some of your old packages don't have 2FA enabled, you will still be asked for an OTP when you attempt to publish a new version of them - unless you have chosen to only use 2FA for authentication and not publishing in your NPM account settings

[fregante]

Now, activating 2FA on your account, however, means that you will always be prompted for OTPs when you publish any package

No, you can choose that. For example you can enable "Authorization only" and you'll be prompted for OTPs:

• when logging in
• when publishing packages that require 2FA

If you intend to publish packages without 2FA in your organization, just don't force it on your whole account.

I just tried this and:

• old package didn't ask for OTP
• new package asked for OTP

[wessberg]

That's exactly what I wrote :-) If you select "Authorization and Publishing", you will be asked for an OTP, no matter the settings of that package. It will be required.

However, if deciding to only use it for "Authorization", as you do I would assume, I guess that yes, it would be possible to opt-in every package one would like to require 2FA for, and that way, it will actually be possible to combine 2FA publishing with non-2FA publishing. I think I'm gonna go ahead and do just that. Awesome! It's cool that you tested it out. It doesn't change anything in terms of me thinking this feature would be a welcome addition to np.

Because I do think that since every or nearly every default behavior of np is opt-out, it seems odd to me that this one isn't. I think np should pick one of two philosophies (constrained vs flexible) and have that be part of every decision like this.