Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

release: false should be the lowest priority rule

オープン
  • 何か問題がありますか？
#377 コメント 2 件 リアクション 3 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
javascript
領域
release, tooling

調査の方向性

リンクされているテストの周辺にある test/analyze-commit.test.js から始め、lib/compare-release-types.js を読み、特に RELEASE_TYPES がどのように比較されているかを確認します。動作を変更する前に analyzer のテストを実行してください。後続のルールが release: false を使用する場合でも、スコープ付きルールがより高い release 値を保持し、既存の release-priority のケースも引き続きパスすれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
JavaScript
スター
446
フォーク
82
平均マージ
7時間 53分
マージ済み PR（30日）
9

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

semantic-release/commit-analyzer のほかの issue

semantic-release/commit-analyzer の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。