Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

release: false should be the lowest priority rule

Abierto
  • ¿Algo no está bien?
#377 2 comentarios 3 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
javascript
Área
release, tooling

Línea de trabajo

Empieza por test/analyze-commit.test.js alrededor del test enlazado y lee lib/compare-release-types.js, especialmente cómo se compara RELEASE_TYPES. Ejecuta los tests del analizador antes de cambiar el comportamiento. Se considera terminado cuando las reglas con ámbito conservan el valor de release más alto cuando una regla posterior usa release: false, mientras los casos existentes de prioridad de release siguen pasando.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
JavaScript
Estrellas
447
Forks
82
Merge medio
7 h 53 min
PR fusionados (30 d)
9

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de semantic-release/commit-analyzer

Todos los issues de semantic-release/commit-analyzer

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.