assets option is ambiguous with git plugin assets option

[esatterwhite]

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.

[babblebey]

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]

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]

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]

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/*"]
  }
}