Analyseur SemVer

Une version n'est pas seulement trois nombres : les identifiants facultatifs de prerelease reliés par des tirets et les métadonnées de build préfixées d'un plus changent l'étiquetage et la comparaison d'une publication. Cet analyseur de version SemVer accepte une seule chaîne, la valide strictement contre la spécification officielle SemVer 2.0.0 et renvoie les composantes numériques major, minor et patch ainsi que tout identifiant de prerelease et de build.

Ce que SemVer 2.0.0 autorise vraiment

Le versionnage sémantique 2.0.0 définit une version comme MAJOR.MINOR.PATCH, trois entiers non négatifs joints par des points, avec des identifiants facultatifs de prerelease après un tiret et des métadonnées facultatives de build après un plus. Chacun de major, minor et patch est un identifiant numérique : soit un zéro isolé, soit un chiffre de un à neuf suivi d'autres chiffres, donc 1.0.0 est valide et 01.0.0 ne l'est pas.

Une version de prerelease est le noyau suivi d'un tiret et d'un ou plusieurs identifiants séparés par des points, comme alpha, rc.1 ou 0.3.4. Un identifiant de prerelease est soit un identifiant numérique avec la même règle d'absence de zéros en tête, soit un identifiant alphanumérique qui contient au moins une lettre ou un tiret et, pour le reste, uniquement des lettres ASCII, des chiffres et des tirets.

Les métadonnées de build suivent un signe plus et utilisent le même alphabet d'identifiants, sauf que les identifiants de build uniquement numériques peuvent garder des zéros en tête, donc 1.0.0+001 est licite. Les identifiants vides, les points consécutifs, un tiret ou un plus final, un v initial, les versions à deux parties comme 1.2 et les lettres non ASCII sont illicites.

Cet analyseur implémente cette grammaire comme un scanneur de gauche à droite, non comme une expression régulière permissive, afin qu'un échec nomme la règle rompue au lieu de renvoyer un objet à moitié parsé. L'ordre de comparaison est hors périmètre : la capacité analyse et valide, elle ne classe pas deux versions l'une par rapport à l'autre.

Où un analyseur SemVer justifie vraiment son usage

Les registres de paquets, les robots de publication et les générateurs de changelog ont besoin d'un seul endroit qui dise si une étiquette est une version SemVer licite et quelles sont ses cinq parties. Un travail d'intégration continue qui refuse de publier lorsque l'étiquette git est v1.2.3 au lieu de 1.2.3, ou lorsque quelqu'un n'a tapé que 1.2, évite une publication cassée avant qu'elle n'atteigne un registre.

Les scanneurs de dépendances qui lisent des lockfiles veulent des champs structurés major, minor, patch et prerelease sans tirer un moteur semver propre à un langage dans un worker de bord. Qui enseigne le versionnage veut une page dédiée qui explique les zéros en tête et les métadonnées de build, plutôt que d'enterrer le sujet sous un simple coupeur de chaînes. Une validation échouée ne consomme pas le solde.

Gardez les chaînes sous la limite de longueur documentée, figez les champs structurés dans les tests, et vous obtenez des composantes reproductibles pour les outils de publication, les greffons d'apprentissage et les workers de bord, sans dresser une bibliothèque semver propre à un langage.