Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Add publish confirmation prompt #96

Closed

Conversation

ruyadorno
Copy link
Contributor

@ruyadorno ruyadorno commented Jan 31, 2020

npm publish should have a confirmation prompt in order to provide a chance for users to review the package contents, similar to how 2FA-enabled users are able to review the contents prior to inputting their OTP.

See RFC

/cc @mikemimik

@ruyadorno ruyadorno added the Agenda will be discussed at the Open RFC call label Jan 31, 2020
@ruyadorno ruyadorno requested a review from a team January 31, 2020 20:41

## Implementation

This is a breaking change from the current `npm publish` behavior, it would prompt the user for confirmation:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps a good first step would be, provide an option to enable the prompt, and then change the default in a future major?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could just make the default be --yes when process.stdout.isTTY === false. Then it'll keep on working for build scripts and CI, but prompt everyone on the CLI.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have plans to align with other package managers? Would be great to have a consistent behavior, I think this is a great idea.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I think we would do this as well in Yarn. cc @zkochan

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine for single-package scenario but I am not sure this would work during a publish in a monorepo. I doubt that someone would review the content of every published package if dozens are published.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if it would only show the prompt if the list of files that are published differs from the list of files in the previously published version?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not all monorepos publish multiple packages at once; in my experience many use independent versioning at this point.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Printing a file diff if possible could be interesting 🤔

Something else to consider is that workflows publishing multiple packages (which do exist, for example this is what we do on Yarn, and I think Babel and Jest do the same) might be more likely to just use --yes (which would be handy, but would kinda negate this RFC altogether).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

multiple packages is common; "bumping all package versions at once even if they haven't changed, to keep all versions the same" is the original lerna behavior that babel, and many others, have thankfully abandoned :-)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarifying Lerna behavior for future reference:

"bumping all package versions at once even if they haven't changed, to keep all versions the same"

This isn't actually what Lerna does in the default "fixed" versioning scheme. It applies a single version to any package (and its local dependents) that has changed since the previous release (annotated git tag).

Not all monorepos publish multiple packages at once; in my experience many use independent versioning at this point.

"Independent" versioning doesn't change anything about how Lerna detects changes between releases or bumps dependents of changed packages, it merely allows one to choose versions per-package instead of globally.

0018-publish-prompt.md Outdated Show resolved Hide resolved
@ruyadorno
Copy link
Contributor Author

ruyadorno commented Feb 19, 2020

Notes from the OpenRFC call:

  • Let's make this an opt-in for npm@7 and then move it to opt-out in a next major release
  • The client has no knowledge on whether 2FA is enabled or not
  • 2FA awareness could/should be addressed in different features / RFCs

@ruyadorno ruyadorno force-pushed the add-publish-confirmation-prompt branch from b1763f9 to 445af22 Compare February 24, 2020 22:21
@darcyclarke darcyclarke added Needs Discussion is pending a discussion and removed Agenda will be discussed at the Open RFC call labels Mar 4, 2020
@ruyadorno
Copy link
Contributor Author

Updated contents of the RFC based on feedback collected during the OpenRFC call and the comments left here 😊 should be ready for ratification if no contention point is raised

@ruyadorno ruyadorno added Agenda will be discussed at the Open RFC call and removed Needs Discussion is pending a discussion labels Mar 4, 2020
accepted/0000-publish-prompt.md Outdated Show resolved Hide resolved
accepted/0000-publish-prompt.md Outdated Show resolved Hide resolved
Co-Authored-By: Jordan Harband <ljharb@gmail.com>
@ruyadorno
Copy link
Contributor Author

cleaned up the RFC and documented all feedback collected 👍 should be good to go

@eridal
Copy link

eridal commented Mar 18, 2020

Is it possible to make the files listed in Tarball Contents be sorted alphabetically?

@darcyclarke darcyclarke removed the Agenda will be discussed at the Open RFC call label Mar 18, 2020
@ruyadorno
Copy link
Contributor Author

@eridal that does sounds a bit outside of the scope of this RFC but that said, it would def be nice to have! 👍

- Changed opt-in flag name to remove reference to "experimental"
@ruyadorno
Copy link
Contributor Author

Updated with feedback from the OpenRFC call removing "experimental" from the name of the option/flag.

@eridal
Copy link

eridal commented Mar 18, 2020

@ruyadorno thanks for your answer

Does that happens here? https://github.com/npm/libnpmpack/blob/ebe5d4790f61f93c7045dd0341f61681ed520899/utils/tar.js#L18

I'd like to attempt to submit a separate PR to address that feature, but that module seems to be currently worked on

@isaacs
Copy link
Contributor

isaacs commented Mar 19, 2020

@eridal Yes, that's currently being worked on by @claudiahdz. Publish and pack will both use the same code path for displaying the tarball contents, and presumably we'd leave that untouched by this RFC. Sorting should be straightforward, I'd think, but I recommend you post an issue on https://github.com/npm/libnpmpack, just so that there's a thing to track.

claudiahdz pushed a commit to npm/libnpmpack that referenced this pull request Mar 26, 2020
This will make `npm pack` output the tarball contents
in an alphabetically and natural sort order.

The current implementation uses `localeCompare` with
the following options:

1. **sensitivity**: `base`, to correctly handle non-ascii letters
  using their base ascii, so that `á`,`â`, `ä`, `ã`, `å` are
  all handled like `a`

1. **numbers**: `true`, to handle numeric filenames as natural
  ascending order so that, for instance, file `10.txt` appears after `9.txt`

---

Convo from npm/rfcs#96

cc @ruyadorno @isaacs
claudiahdz pushed a commit to npm/libnpmpack that referenced this pull request Mar 26, 2020
This will make `npm pack` output the tarball contents
in an alphabetically and natural sort order.

The current implementation uses `localeCompare` with
the following options:

1. **sensitivity**: `base`, to correctly handle non-ascii letters
  using their base ascii, so that `á`,`â`, `ä`, `ã`, `å` are
  all handled like `a`

1. **numbers**: `true`, to handle numeric filenames as natural
  ascending order so that, for instance, file `10.txt` appears after `9.txt`

---

Convo from npm/rfcs#96

cc @ruyadorno @isaacs
claudiahdz pushed a commit to npm/libnpmpack that referenced this pull request Mar 26, 2020
This will make `npm pack` output the tarball contents
in an alphabetically and natural sort order.

The current implementation uses `localeCompare` with
the following options:

1. **sensitivity**: `base`, to correctly handle non-ascii letters
  using their base ascii, so that `á`,`â`, `ä`, `ã`, `å` are
  all handled like `a`

1. **numbers**: `true`, to handle numeric filenames as natural
  ascending order so that, for instance, file `10.txt` appears after `9.txt`

---

Convo from npm/rfcs#96

cc @ruyadorno @isaacs
@darcyclarke darcyclarke removed this from the OSS - Sprint 7 milestone Jun 1, 2020
@ruyadorno ruyadorno added the Agenda will be discussed at the Open RFC call label Jul 15, 2020
@darcyclarke darcyclarke removed the Agenda will be discussed at the Open RFC call label Jul 22, 2020
@ruyadorno
Copy link
Contributor Author

Landed in 0ad3bdc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants