Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

release: false should be the lowest priority rule

Offen
  • Stimmt etwas nicht?
#377 2 Kommentare 3 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
javascript
Bereich
release, tooling

Rechercherichtung

Beginne mit test/analyze-commit.test.js rund um den verlinkten Test und lies lib/compare-release-types.js, insbesondere, wie RELEASE_TYPES verglichen wird. Führe die Analyzer-Tests aus, bevor du das Verhalten änderst. Erledigt ist die Aufgabe, wenn Regeln mit Scope den höheren Release-Wert beibehalten, wenn eine spätere Regel release: false verwendet, während bestehende Fälle mit Release-Priorität weiterhin bestehen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
JavaScript
Sterne
446
Forks
82
Ø Merge
7 Std. 53 Min.
Gemergte PRs (30 T.)
9

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus semantic-release/commit-analyzer

Alle Issues in semantic-release/commit-analyzer

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.