Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

release: false should be the lowest priority rule

Ouverte
  • Quelque chose ne va pas ?
#377 2 commentaires 3 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
javascript
Domaine
release, tooling

Piste de recherche

Commencez par test/analyze-commit.test.js autour du test associé et lisez lib/compare-release-types.js, en particulier la façon dont RELEASE_TYPES est comparé. Exécutez les tests de l’analyseur avant de modifier le comportement. C’est terminé lorsque les règles avec scope conservent la valeur de release la plus élevée lorsqu’une règle ultérieure utilise release: false, tandis que les cas existants de priorité de release continuent de passer.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Consider what happens when we expand this test to apply scope:

test('Return "false" for release type ONLY if the matching rule has no higher "release"', (t) => {
  const commit = {type: 'fix', scope: 'frontend'};

  t.is(analyzeCommit([
    {type: 'fix', scope: 'frontend', release: 'patch'},
    {type: 'fix', scope: '*', release: false} // <----- this should NOT override 'patch'
    ], commit), 'patch');
});

so this ruleset says "release fixes as 'patch' for the frontend, but don't release any other fixes in any other scopes"

this test will fail. because of this line: https://github.com/semantic-release/commit-analyzer/blob/master/lib/compare-release-types.js#L11

RELEASE_TYPES doesn't include false or null. so the algorithm starts to analyze our commit using our ruleset, and correctly identifies it as a 'patch'. then it considers the next rule, which says release === false. false is not in RELEASE_TYPES, so compareReleaseTypes() returns true, and the release value for the commit is incorrectly set to false, instead of patch.

this is problematic because it violates the advertised behavior of the release configuration: a commit will always be given the highest possible release value available from the given ruleset. if we consider "no release" the lowest possible release value - as I think is intuitive - then any other release value should take precedence.

the current algorithm treats no release as a special case without priority. or rather, it implicitly treats no release as the highest possible priority of release type, which doesn't make sense. no release cannot be the biggest release.

the current behavior thus renders the use case I've alluded to impossible, so i'll spell that use case out more specifically.

if you have a repo with several scopes, then you might want rules that govern how some scopes get released, and you might want only some of those scopes to get released ever. for example, if you have a project like this:

project/
  - frontend
  - backend
  - shared-tools

you might want to say something like this:

"release any frontend or backend commits according to standard rules. fix:patch, feat:minor, break:major. but don't ever release any commits in shared-tools no matter what."

here's an example of what that ruleset might look like:

[
  {scope: 'frontend', type: 'fix', release: 'patch'},
  {scope: 'frontend', type: 'feat', release: 'minor'},
  {scope: 'frontend', type: 'breaking', release: 'major'},
  {scope: 'backend', type: 'fix', release: 'patch'},
  {scope: 'backend', type: 'feat', release: 'minor'},
  {scope: 'backend', type: 'breaking', release: 'major'},
  {scope: '*', type: '*', release: false}
]

but for the reasons explained so far, that ruleset will never do what you expect. it will make any release impossible.

the simplest fix and what i would recommend is adding false, and null to the end of the list of RELEASE_TYPES. this would be a breaking change for people who expect release: false|null to override any other possible release value. but that perspective doesn't make any sense, and renders reasonable workflows impossible.

Langage dominant
JavaScript
Étoiles
446
Forks
82
Merge moyen
5 j 10 h
PR mergées (30 j)
14

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de semantic-release/commit-analyzer

Toutes les issues de semantic-release/commit-analyzer

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.