feat: add prompt to update npm publish config

[zcf0508]

• <- Keep this line and put an x between the brackts.

Description

This PR introduces a new CLI option --npm-tag to manage the npm publish tag (e.g., latest, beta, next) during the release process.

Why?
Previously, bumpp did not offer a built-in way to modify the publishConfig.tag during the version bump process. Users who needed to publish to a specific tag (common for prereleases like v1.0.0-beta.1) had to manually edit package.json or rely on external scripts.

When you publish a prerelease version, npm will throw an error :
npm error You must specify a tag with --tag when publishing a prerelease version.

Key Changes:

1. New --npm-tag Option:

   • Default (No Flag): Zero config, zero noise. The publishConfig in package.json is left untouched. This preserves the existing behavior and avoids accidental changes.
   • Interactive Mode (--npm-tag): Prompts the user to confirm or input the publish tag. The default value is intelligently inferred (e.g., beta for 1.0.0-beta.1, latest for 1.0.0).
   • Explicit Mode (--npm-tag <tag>): Directly sets the tag (e.g., bumpp --npm-tag beta) without prompting, ideal for CI/CD or scripts.

2. Smart Manifest Updates:

   • Updates publishConfig.tag in package.json only when explicitly requested via the new flag.
   • Clean-up Logic: If the selected tag is latest, it automatically removes the tag field from package.json (as latest is the default). If publishConfig becomes empty, the entire object is removed to keep the file clean.
   • Safety: Preserves other existing fields in publishConfig (like access: "public"), ensuring no configuration is lost.

3. Monorepo Support:

   • Verified that changes apply correctly across multiple packages in a monorepo setup.

Linked Issues

N/A

Additional context

I have added new test cases in test/publish-tag.test.ts covering:

• CLI argument parsing for --npm-tag.
• Tag inference logic.
• Various package.json update scenarios (add, update, remove tag).
• Handling of extra fields in publishConfig (e.g., access).
• Monorepo update verification.

[antfu]

I am not so sure if we should write the tag into the package.json

[antfu]

While I love this idea, I am a bit worried this could be a bit too annoying as I see 95% of the time I would want to publish to latest and in very rare cases I need to publish to a different tag (for example, when doing beta releases in another branch, I would only publish packages to the beta tag, and I could configure or update the command for a specific branch, prompting everytime can also increse the chance of mistakes).

[zcf0508]

I have an idea that we could add a command parameter like --change-publish-tag or something.

By default, this parameter is false, and the publish tag prompt will not be shown. If mantainer wants to publish the current version to another tag like beta, he can run bumpp --chang-publish-tag locally and then the publish tag prompt will be shown to confirm the tag name.

[antfu]

Also noting that even with 1.0.0-beta.0, not in all the cases we want to publish to the beta tag - sometimes the maintainer would publish to latest on purpose to get more awareness, for example.

So my main concern is that if this would create more trouble than it would help.

[zcf0508]

I just realized that adding the publishConfig key could break lint check.