Skip to content

assets option is ambiguous with git plugin assets option #808

New issue
New issue
Open
#809
Open
assets option is ambiguous with git plugin assets option#808
#809
@esatterwhite

Description

@esatterwhite
esatterwhite
opened on Apr 5, 2024 · edited by hearts

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.

Activity

esatterwhite
added a commit that references this issue on Apr 5, 2024

feat: Add githubReleaseAssets option

1aed3e4
esatterwhite
linked a pull request that will close this issue on Apr 5, 2024
esatterwhite
added a commit that references this issue on Apr 10, 2024

feat: Add githubReleaseAssets option

0370eb5
esatterwhite
added a commit that references this issue on Apr 17, 2024

feat: Add githubReleaseAssets option

8a17388
babblebey

babblebey commented on Aug 13, 2024

@babblebey
babblebey
on Aug 13, 2024 · edited by hearts
Member

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.

I can easily assume that this is how the configurations functions. I'd suggest we make this possible instead of a rename.

I'm interested in understanding the initial thought process behind having the property named assets (i.e. keeping'em uniform) across the plugins and the package itself too 🤔

esatterwhite

esatterwhite commented on Aug 13, 2024

@esatterwhite
esatterwhite
on Aug 13, 2024 · edited by hearts
Author

I can easily assume that this is how the configurations functions. I'd suggest we make this possible instead of a rename.

It isn't possible to have a single configuration option represent multiple settings.

module.exports = {
  assets: ['package.json', '*.md', '!**/node_modules/**'],
, plugins: [...]
}

There is no way for me to define what gets added to a git commit independently from what is added to a github release without either losing extensibility, or introducing a good amount of complexity.

gr2m

gr2m commented on Aug 14, 2024

@gr2m
gr2m
on Aug 14, 2024 · edited by hearts
Member

I don't agree, or maybe don't yet understand why this is better

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

Than this

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

I think being able to define a global default and then override it on a plugin level is a feature, not a bug

esatterwhite

esatterwhite commented on Aug 14, 2024

@esatterwhite
esatterwhite
on Aug 14, 2024 · edited by hearts
Author

When you extend this as a shareable config, config that is defined at inline with the plugin rather than set globally, it requires the end user to redefine the entire plugin stack so the configuration still works correctly. Which isn't really feasible without being intimately familiar with all of the plugin settings and the setup of the config.
So rather than just being able to extend and set 1 or 2 things

//  release-config-base62
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  changelogTitle: '## Changelog',
  assets: ['package.json', '*.md', '!**/node_modules/**']
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git']
    ['@semantic-release/exec', null],
    ['@semantic-release/github', {
       assets: ['dist/*.tgz', 'coverage/*.json']   // <---- we have to do this here because github assest rarely match git assets
    }]
  ]
}

Attempting to do this doesn't do what one would expect

{
  // package.json
 "release": {
    "extends": "base62"
  ,  "assets": ["*.md", "package.json", "*.rocskec"]   
  }
}

Not only does this not change the github config, it changes the git config
everyone extending this config has to re-create the plugin chain in the right order and any nested configurations

{
  // package.json
 "release": {
    "extends": "base62"
  , "plugins": [
      ['@semantic-release/commit-analyzer', null],
      ['@semantic-release/release-notes-generator', null],
      ['@semantic-release/changelog', null]
      ['@semantic-release/npm', null],
      ['@semantic-release/git']
      ['@semantic-release/exec', null],
      ['@semantic-release/github', {
        "assets": ["*.md", "package.json", "*.rocskec"]             // <---- override
      }]
    ]
  }
}

If the base config introduces a new plugin or other such things, its a breaking change every time because everyone else now has to update the plugin list. Its confusing, brittle and not very extensible.

I should be able to just set the 1 or 2 things and plainly understand which thing I'm changing.

{
  // package.json
 "release": {
    "extends": "base62"
  ,  "gitAssets": ["*.md", "package.json", "*.rocskec", "**/*.lua"]   
  , "releaseAssets":  ["dist/*.tgz", "coverage/*.json", "build/*"]
  }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @gr2m@esatterwhite@babblebey

      Issue actions
        assets option is ambiguous with git plugin assets option · Issue #808 · semantic-release/github