Auto: Utiliser npm comme source de vérité de la version

Oooh j'aime ça. Cela pourrait devenir difficile pour les monorepos cependant

Puisque nous faisons --force-publish=* pour lerna, cela ne devrait pas être un problème puisque tous les packages devraient avoir une version liée.

À l'avenir, si nous supprimons ce drapeau, nous devrons... idk

De plus, nous exécutons simplement npm version qui ne prend qu'une chaîne semver. Nous ne définissons aucun numéro de paquet pour le moment. Ce ne serait pas trop difficile de le régler nous-mêmes, mais les monorepos semblent à nouveau ne pas être simples

La plupart des commandes fonctionnent également sur les balises, donc si la version n'était pas balisée, cela pourrait causer des problèmes.

https://github.com/azu/can-npm-publish

"Je suis de plus en plus convaincu que le mode de gestion des versions "indépendant" était une erreur. Tout ce qu'il fait, c'est que les gens jettent des packages aléatoires dans un seul référentiel, puis se plaignent lorsqu'ils doivent les versionner en même temps. " ~ du mainteneur de lerna.

Donc --force-publish=* semble bien.

--force-publish et le versioning indépendant ne sont pas la même chose.
Par défaut, lerna ne publiera une mise à jour d'un paquet que s'il y a des modifications, en utilisant --force-publish=* nous forçons lerna à publier une version de tous les paquets même s'il n'y a pas de changement depuis la dernière publication.

c'est-à-dire que le package A a des modifications, B n'en a pas. lerna ne publiera qu'une nouvelle version de A ( B restera à sa version actuelle). La prochaine version A et B ont des changements, ils seront tous les deux publiés avec la même nouvelle version.

Une chose à laquelle j'ai pensé (et je ne suis pas sûr que ce soit une chose que nous soutiendrons un jour) est le potentiel de versions qui ne sont pas master (ou la branche principale). Jusqu'à présent, nous avons toujours supposé qu'il y avait 1 chemin à suivre pour les versions -- et elles sont toujours linéaires (en utilisant la version latest sur npm ou github).

Que se passe-t-il en cas de besoin de patcher une version précédente ? (1.x a un bug, master est sur 2.x mais vous voulez patcher 1.xw/ un correctif aussi) Si nous sortons du lerna ou du pkg Version

Si nous modifions cela pour utiliser quelque chose en dehors de l'arbre git, je ne pense pas que nous serions en mesure de prendre en charge ce comportement, car il n'y a jamais que 1 latest sur npm (ou partout où nous récupérons la dernière version)

Cela semble être une bonne fonctionnalité. La mise en œuvre peut demander un certain travail.

version:

• Nous calculons version utilisant la dernière version - cela pourrait-il facilement passer à la version du package ?
• La dernière version sur github peut poser problème. Je ne pense pas que vous puissiez réellement définir par programme la "dernière version". Ainsi, lors de la publication d'un correctif vers 1.x, il deviendrait la dernière version.

version/journal des modifications

• getCurrentVersion renvoie lastRelease si gt(lastRelease, lastVersion) - il faudrait donc en tenir compte également

cela signifie que nous utilisons déjà des éléments en dehors de l'arbre git, n'est-ce pas ?

Nous devons dépendre de lastRelease pour nous assurer qu'une balise git lui est associée, donc la commutation n'est pas une option car nous ne pouvons pas être sûrs que la dernière version de npm a une balise (comme dans ce que ce problème décrit) .

Je pense que nous aurions probablement besoin d'un nouveau drapeau qui versions de la dernière balise git. --from-git

Avec cela, la commande de libération fonctionnerait probablement. Nous aurions à trier à quoi ressemble le changelog.

le drapeau --from-git pourrait également remplacer la recherche de NPM pour n'importe quoi. Je pense que cela signifie que nous pouvons fusionner #173