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

assets option is ambiguous with git plugin assets option

Abierto
  • ¿Algo no está bien?
#808 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
git, github, javascript
Área
release, tooling

Línea de trabajo

Comienza rastreando cómo los plugins git y github resuelven la opción compartida de nivel superior assets y cómo las opciones específicas de los plugins la sobrescriben. Revisa el comportamiento existente de configuración y compatibilidad antes de decidir cómo deberían funcionar los nombres distintos. Se considera completado cuando los assets de git commit y los assets de versiones de GitHub se pueden configurar de forma independiente, mientras las configuraciones existentes de assets siguen funcionando.

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

Descripción

Both the git plugin and github plugin have a configuration option named assets. When building out a shareable configuration, It is preferable to omit configuration inline with the plugin and define as much as possible in the top level of the release config so they can be overridden when the configuration is extended.

// my-release-config/index.js
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  assets: ['package.json', '*.md', '!**/node_modules/**'],  // <---- assets
  changelogTitle: '## Changelog',
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git', null],
    ['@semantic-release/exec', null],
    ['@semantic-release/github', null]
  ]
}

This works rather well except when you use the git and github plugins together - the assets configuration is ambiguous meaning. In the above example, All .md files will be included in both the release commit, and the files attached to the github release. if the value needs to be different between the two plugins, you have to define the plugin configuration inline, which makes it difficult to change

// my-release-config/index.js
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  changelogTitle: '## Changelog',
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git', {
      assets: ['package.json', '*.md', '!**/node_modules/**'] // <---- assets
    }]
    ['@semantic-release/exec', null],
    ['@semantic-release/github', {
       assets: ['dist/*.tgz', 'coverage/*.json']              // <---- assets
    }]
  ]
}

This allows them to be different, But now you cannot really over ride these values individually with out modifying them both, or changing them in the actualy config package being exteded. Which mean people have to re-define the entire plugin change and re-create most of the default configuration shipped with the shared config. Which mostly defeats the purpose.

Ideally, these settings should be named differently to disambiguate them - gitCommitAssets and githubReleaseAssets.
Something to this effect. It could initially be alternate value to allow the existing assets value to work if defined like it currently does.

Lenguaje dominante
JavaScript
Estrellas
535
Forks
150
Merge medio
5 d 16 h
PR fusionados (30 d)
11

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/github

Todos los issues de semantic-release/github

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.