Déployer un package sur npm de manière automatisée et en respectant SemVer avec semantic-release

Respecter SemVer (presque) sans avoir à y penser avec semantic-release

Semantic Versioning

X.Y.Z

Major

Minor

Patch

Breaking

Feature

1.0.0
1.0.1
1.1.0
2.0.0

Fix d'un bug

Ajout d'une feature, sans modification de l'API existante

Modification de l'API

SemVer est un contrat que vous signez avec vos utilisateurs, une forme de respect qui leur permet d'adapter leur code ou non en fonction des versions que vous proposez.

-- « SemVer, c'est quoi ? », putaindecode.io

Publier un module sur npm

Incrémente X, Y ou Z dans le package.json; crée un commit de version et un tag

$ npm version [major | minor | patch]

Envoie les fichiers du module sur le registry npm

$ npm publish

Alors, quel est le problème ?

Problème n°1 : nous sommes humains

after all.

🤔

Major ?

Minor ?

Patch ?

Breaking or not breaking ?

MEH.

type(scope): subject

body

footer
type

          : feat / fix / chore / refactor / perf / style / test...

scope

            : décrit la partie du code à laquelle les changements s'appliquent

subject

                : description succinte des changements

: description longue des changements

: références, breaking changes

feat(pencil): add 'graphiteWidth' option
fix(graphite): stop graphite breaking when width < 0.1

Closes #28
perf(pencil): remove graphiteWidth option

BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reason.

Patch release

Minor release

Major release

Problème n°2 : une release, ce n'est pas qu'une incrémentation du numéro de version et une publication sur le registry

Exemple de cozy-ui

  • Mettre à jour le master local

  • Incrémenter la version dans le package.json (en respectant semver)

  • Mettre à jour le changelog (à générer avec lerna-changelog, qui se base sur les tags des PR pour savoir ce qui est un fix, une feature, un breaking change)

  • Mettre à jour les liens en bas du changelog

  • Commit et push ces changements

  • Créer la release dans l'interface Github

feat(pencil): add 'graphiteWidth' option
perf(pencil): remove graphiteWidth option

BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reason.
fix(graphite): stop graphite breaking when width < 0.1

Closes #28

Bug fixes

  • Graphite
    • Stop graphite breaking when width < 0.1

New features

  • Pencil
    • add 'graphiteWidth' option

Performance improvements

  • Pencil
    • Remove graphiteWidth option

Breaking changes

  • The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reason

Problème n°3 : pourquoi attendre n commits / PRs pour sortir une release ?

AUTOMATISER

Une seule solution :

📦🚀 semantic-release

Fully automated version management and package publishing

Push sur la
« release branch »

Build CI

Tests

Release

La publication d'une nouvelle release ne nécessite plus d'autre action humaine qu'un git push

Démo ?

Démo !

Déployer un package sur npm de manière automatisée et en respectant SemVer avec semantic-release (formation Cozy)

By Cyrille Perois

Déployer un package sur npm de manière automatisée et en respectant SemVer avec semantic-release (formation Cozy)

  • 662