It does look like this change causes some issues with the current test suite – I can continue to look into that if this seems like something that you would want to move forward with. This has been resolved.

Along with the Object.assign order... this seems wrong, but is required based on defaults coming from both ./defaults and in argv via ./command in this file.

Coverage decreased (-0.3%) to 99.74% when pulling a6a0109 on jbottigliero:feat-configuration into 844cde6 on conventional-changelog:master.

Coverage remained the same at 100.0% when pulling a27ded2 on jbottigliero:feat-configuration into 387eaae on conventional-changelog:master.

@jbottigliero sorry for dropping this on the floor forever, this project is definitely in need of a couple more maintainers. If you'd still like to work on seeing this over the finish line, you can find me here:

http://devtoolscommunity.herokuapp.com/

It's a good place to prod me, and make sure that we're moving features forward.

@jbottigliero reading through your pull request a bit, I'm a strong 👍 on this functionality. I believe we might be able to use yargs directly for some of the feature set though, see:

https://github.com/yargs/yargs/blob/master/docs/api.md#configobject

https://github.com/yargs/yargs/blob/master/docs/api.md#pkgconfkey-cwd

and finally,

https://github.com/yargs/yargs/blob/master/docs/advanced.md#building-configurable-cli-apps

My goal with standard-version and nyc has been to use them as testing grounds to help drive development on yargs (the goal being to ensure yargs provides a lot of the functionality you'd commonly want in a CLI in an elegant way).

@jbottigliero please feel free to message me here to help coordinate landing this.

@bcoe – I've updated the PR to utilize yargs.config.

I'm still opting for a custom parseFn at the moment based on configuration properties allowing functions (ie. whatBump in conventional-recommended-bump) – let me know if I'm missing something in the yargs docs, but this seems like the best way to handle it.

I've also added a few tests for preset configuration cases. These should cover the new --preset flag and this configuration.

I'll catch up with you on chat, but here is what I'm thinking:

• This PR:

  • Add test(s) for conventional-recommended-bump option(s)
  • Update documentation (README.md) to include --config

• Follow-Up PR:

  • Move all pass-thru configurations to a default --config handled value.
  • Remove pass-thru configuration yargs params (ie. --preset)

@jbottigliero I'm happy with this compromise 👍

Looks like the tests failing are just a linting issue.

The tests should now pass, but I've run into a bit of a predicament around the best way to pass options to conventional-changelog(-core).

The "problem" is that preset is a special case configuration option that alters the configuration that is actually passed to conventional-changelog-core (https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog/index.js#L9-L11).

In my latest update, I'm passing along the options as both options and context to act as a sort of override...

It seems like the "right" answer might be to explicitly pass conventional-changelog-core options as context to conventional-changelog via (conventionalChangelog) requiring the configuration object to look something like:

{
  "standard-version": {
    "modules": {
      "conventional-changelog": {
        "preset": "@some/preset"
      },
      "conventional-changelog-core": {
        "host": "gitlab"
      }
    }
  }
}

Additionally, I'd guess that tagPrefix isn't working in some cases (in conjunction with a preset) based on how is currently being passed.

edit not passing on Node 6 due to the spread operator, I'll swap this for Object.assign based on a decision on direction.

@jbottigliero what's preventing us from the right solution right now, do we need to change the API surface in some of the dependent libraries? I don't think we should be shy about making any changes that you need in conventional-commits, we have the commit bit.

@bcoe – I think it's really just my understanding/expectation of how the configurations are actually being merged in conventional-changelog-core.

I've updated the PR to pass along conventional-changelog configuration as options and conventional-changelog-core configuration as context and added a few tests scenarios -- things are passing. But I think I need to read through the mergeOptions a bit more to feel confident in this solution.

@jbottigliero thanks for updating, I'll make an effort to start looking at some of the outstanding issues on standard-version soon (hopefully this weekend). There are a bunch of issues open related to making the library more easily configurable, I'll do my best to find a common thread between them all, and to start landing some patches.

@jbottigliero this is the conversation specifically on my mind:

#195 (comment)

I would like it to be easier to configure CHANGELOG generation and bump criteria, furthermore I'd like to move towards using a convention based on conventionalcommits.org.

@jbottigliero mind if I use this as a bases for adding in the new configurable conventionalcommits preset? or do you have the cycles to do so right now?

@bcoe – I should be able to make this switch!

@jbottigliero let me flag you on a PR with some thoughts I have, now that you've done work to standardize our config format, my preference would be that we load configuration from an rc file demonstrated here:

https://github.com/bcoe/c8/blob/master/lib/parse-args.js#L86

@jbottigliero only closed this momentarily, will have a new PR open in a sec we can collaborate on -- I have some thoughts about how we might use the spec you're writing.

@jbottigliero don't suppose I could convince you to join this slack:

http://devtoolscommunity.herokuapp.com/

so that we can coordinate work in real time?

Any update on this feature?