Auto: Plugin : appliquez des étiquettes de relations publiques basées sur des messages de validation de style sémantique

C'est assez bizarre comment cela dépend de l'ESM

Il devrait probablement utiliser esm pour la construction et non en production

c'est un peu comme utiliser babel-register au lieu de simplement le construire et publier le dossier dist

Je pensais la même chose au début, mais un coup d'œil au code source dit le contraire.

edit : Oh nvm, vous dites que esm peut être utilisé pour compiler avant la publication. Nous devrions envoyer un PR.

Cela ressemble à un bon module sinon. Gentil et maigre

On dirait que esm n'est pas fait pour la compilation : https://github.com/standard-things/esm/issues/13#issuecomment -321710199

Je dis que nous bifurquons pour l'instant et convertissons la syntaxe import et export en CommonJS.

hmm ouais je lisais juste le readme. On dirait que j'ai mal compris

esm semble ajouter 65kb 😮

https://packagephobia.now.sh/result?p=parse-commit-message
https://bundlephobia.com/[email protected]

Je ferai un pr pour passer à https://github.com/developit/microbundle et peut-être qu'il l'ajoutera.

Vous devriez envisager d'utiliser https://github.com/egoist/bili à la place. Il a la moitié de la taille d'installation, mais il peut avoir d'autres compromis. Pas certain.

https://github.com/tunnckoCoreLabs/parse-commit-message/pull/55

Au fait, pour rejoindre la fête. git-commits-since et detect-next-version pourraient être plus utiles ici ?

J'utilise esm cause des garanties et parce que c'est derrière l'indicateur de fonctionnalité esm du nœud. Je pourrais facilement utiliser ascjs ou similaire comme rewrite -imports , mais esm prend en charge bien plus que la simple importation/exportation. Et parce que je n'ai pas _any_ étape de construction ou quoi que ce soit, pour les tests, je l'utilise simplement comme crochet pour mon coureur.

Ce qui nous amène à cela, nous pouvons passer à ascjs ou asbundle .

@aleclarson pourquoi la taille est-elle si problématique ? Même au pays des nœuds, nos gestionnaires de paquets sont déjà assez intelligents pour dédupliquer.

@aleclarson pourquoi la taille est-elle si problématique ? Même au pays des nœuds, nos gestionnaires de paquets sont déjà assez intelligents pour dédupliquer.

Je n'ai jamais mentionné les dépendances en double comme un problème. Je me méfie juste des outils gonflés en général. "Plus c'est léger, mieux c'est" est ma règle d'or, mais à chacun son goût. Je ne suis pas vraiment intéressé à en débattre. :)

Au fait, pour rejoindre la fête. git-commits-since et detect-next-version pourraient être plus utiles ici ?

Je préférerais utiliser parse-commit-message car ces packages semblent dupliquer la logique qui existe déjà dans auto-release , mais peut-être que @hipstersmoothie serait prêt à remplacer la logique existante par ces packages pour réduire le fardeau de la maintenance.

:rocket: Le problème a été publié en 10.0.0 :rocket: