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

assets option is ambiguous with git plugin assets option

Offen
  • Stimmt etwas nicht?
#808 4 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@esatterwhite arbeitet bereits daran.

Seit 05.4.2024.

  • #809 von @esatterwhite — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
git, github, javascript
Bereich
release, tooling

Rechercherichtung

Beginne damit nachzuverfolgen, wie die git- und github-Plugins die gemeinsame assets-Option der obersten Ebene auflösen und wie pluginspezifische Optionen diese überschreiben. Überprüfe das bestehende Konfigurations- und Kompatibilitätsverhalten, bevor du entscheidest, wie unterschiedliche Namen funktionieren sollen. Erledigt ist die Aufgabe, wenn git-Commit-Assets und GitHub-Release-Assets unabhängig voneinander konfiguriert werden können und bestehende assets-Konfigurationen weiterhin funktionieren.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
JavaScript
Sterne
537
Forks
147
Ø Merge
25 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/github

Alle Issues in semantic-release/github

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

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