Allow users to config commit-analyzer

[kentcdodds]

If I improve performance, and that's all I do, I still want a release. Is there any problem with this?

[boennemann]

Hey @kentcdodds,

actually I wanted to make this part of the next breaking release ;) There are some more changes planned for how the commit plugin works (See here) and the underlying module changed/improved so it'll probably still take some time, but it will land eventually.

Best,
Stephan

[wilmoore]

@boennemann The next release looks cool; however, how does one achieve this now (besides writing a new analyzer)?

If a new analyzer is the answer, @kentcdodds, let's collab on it as I really want all changes that match one of the approved types to generate a release. Most of which would be patch releases.

[kentcdodds]

I wish I had more time to devote to this, but I don't right now. If I get some time, I'd happily collaborate if @boennemann hasn't gotten to it yet.

[boennemann]

@wilmoore @kentcdodds The fastest way would be to just change !type && commit.type === 'fix' to !type && (commit.type === 'fix' || commit.type === 'perf') here: https://github.com/semantic-release/commit-analyzer/blob/master/src/index.js#L20

If you send me PR I'll release that as a "next" version of this module and you can just overwrite the default analyzer with this one, until we get to ship it as a default.

Does that sound good?

[kentcdodds]

Sounds good to me. I'll leave @wilmoore to do the PR if he likes. I don't need this immediately.

[wilmoore]

I'd actually like to see all of the following trigger a patch release:

• docs
• refactor
• chore
• test
• fix
• perf

If agreed, I'm happy to do the PR.

[kentcdodds]

I disagree with:

• refactor
• chore
• test

The others I'm good with. But I expect some might not like docs to release because it's not a code change. Would be coolest if it were configurable...

[wilmoore]

@boennemann

Here is the PR: semantic-release/commit-analyzer#4

@kentcdodds

Perhaps we can iterate on a configuration design going forward; however, I took a pragmatic approach and made the list above resolve to patch releases.

[boennemann]

@wilmoore @kentcdodds Sorry I didn't see the forest for the trees here. The plugin already supports being passed pluginConfig. How about making the respective types configurable and using the current behavior as a default?

[kentcdodds]

How would one utilize pluginConfig? Is that in the package.json?

[boennemann]

In the package.json

"release": {
  "anaylzeCommits": {
    "minor": ["feat"],
    "patch": ["fix", "perf"]
  }
} 

Something likes this could work? :)

[kentcdodds]

That would be perfect 👍

[hutson]

👍 Agreed

[pensierinmusica]

I think this would solve most issues and be very desirable: semantic-release/commit-analyzer#12

I sent a PR for it: semantic-release/commit-analyzer#13

Then of course the rest of this thread holds true, and the user could always override the default behaviour configuring the plugin as suggested here: semantic-release/commit-analyzer#3 (comment)

Thoughts?