meteor/meteor
Document --release option on meteor publish command
Ouverte
#12 954 ouverte le 8 janv. 2024
confirmedgood first issueidlemissing-docs
Métriques du dépôt
- Stars
- (44 781 étoiles)
- Métriques de merge PR
- (Merge moyen 9j 9h) (21 PRs mergées en 30 j)
Description
Using Meteor 2.14 I can enter meteor publish --help which gives the following documentation:
Usage: meteor publish [--create]
meteor publish --update
Publishes a new version of a local package to the package server. Must be run
from the directory containing the package. Reads the package.js file for version
information, builds the package and sends both the package source and the built
version of the package to the package server.
This will create at most one build of the package. If the package has an
OS-dependent binary component, publishing will only register metadata about the
package. The binary component will be compiled when it is installed into an
application with `meteor add`. To pre-build a package for a particular platform,
use the `meteor publish-for-arch` command.
This will mark you as the only maintainer of the package. You can use
'meteor admin maintainers' to change package maintainers. For more information
about admin commands, run 'meteor help admin'.
Change the metadata for a given version of a package by running with the
--update flag. That will set the git url, version summary, longform description
and documentation in the database to their new values. You can use 'meteor show'
to preview the results.
Pass --create to create a new package.
Options:
--create publish a new package
--update changed metadata of a previously published version
--allow-incompatible-update Allow packages in your project to be upgraded or
downgraded to versions that are potentially incompatible with the
current versions, if required to satisfy all package version
constraints.
--no-lint don't run linters on the published package and its local
dependencies before publishing
However, I didn't know that I can actually use --release here in order to resolve "top-level" version conflicts, which was recently a big blocker when attempting to publish packages for 3.0 beta.
This option should be added to the help and maybe also to the migration docs. Might be crucial for people who struggle with migrating packages.