Use conventional-commit-types

[AndersDJohnson]

You may wish to integrate my new conventional-commit-types module which exposes a simple list of valid commit types used in this module (plus revert per Angular conventions).

I wanted a standalone module for these so I could use them in other tools, e.g. my new conventional-commit-types-cli. Alternatively, this module could be refactored to expose them, if you prefer that.

I can consider giving ownership of these new repos and modules to @commitizen.

[jimthedev]

Love it. It would be my pleasure to add you as a contributor to the commitizen organization if you would be willing to help work on a type system. My main goals are that it should be deterministic, flexible, and able to support introspection.

I notice right now that you're using JSON for the types. I'm a bit more partial to something like the type system in GraphQL. I know most people aren't familiar with it but I want to make sure that adapters can pick and choose types from different type sets.

Some adapter authors may want to use docs but not chore for example. I'd like for them to be able to pick types from different typesets and bring them into their adapter.

Why do we need this kind of thing? Well it turns out that many people want to hide or show certain fields or prompts in certain cases, alternatively they may want to change the commit behavior in certain cases. This functionality will likely be different for each adapter, but the types can be shared across adapters.

Take #23 as an example. He wants to use the same types as everyone else but be able to just detect certain types and modify the commit behavior in those cases.

In other cases people want to extend the default type set (see #15).

We have a PR waiting to be merged: #25 which breaks apart the prompting and formatting. I think we could take this further and break formatters up into formatting logic and the specific types they want to use.

I know this is probably a lot more than you signed up for, but, there is certainly a need for work in this area and if you're able to help we'd love to have it.

[AndersDJohnson]

@jimthedev What about adding support to https://github.com/commitizen/cz-cli for a new config.commitizen.types key in .czrc and package.json (similar to config.commitzen.path per docs) that would allow users to specify their own module, instead of the new default of conventional-commit-types, that will export their preferred types in the same JSON format?

E.g. I could create my own module called my-commit-types with a main script index.js like:

var types = require('conventional-commit-types')

types = Object.assign({}, types, {
  myType: {
    description: 'A custom type'
  }
})

delete types['revert']

module.exports = types

Or even an index.json as main like:

{
  "myOnlyType": {
    "description": "A lonely type"
  }
}

Adapters could publish their types as an external module for reuse in other tooling, then require and use those types from their adapter code. So e.g. the transform method in the angular adapter could just require and iterate to reduce some repetitive logic.

We could have a JSON Schema to specify the types object. It could allow additional properties so adapters could put relevant metadata there if desired.

I might change the schema to have a types key at root containing the types, to allow for other root-level keys for future extensibility.

[LinusU]

Instead of adding an extra field to the package.json that only applies to some adapters, wouldn't it be more nice to split the adapter up in two packages.

One package would take a lists of types, and then do all the work (e.g. cz-conventional-changelog-engine), and the other part would just require and call that module with the default list.

That way it will be easy to publish new adapters that simply modifies the list of types, without having to introduce another concept of loading adapters.

Thoughts?

[AndersDJohnson]

@LinusU Sounds good to me. @jimthedev shall we pursue this sort of refactor? Want to get through any pending PRs or major upcoming changes first?

[jimthedev]

I don't. Let's do it.

Jim ForCy

On August 9, 2016 at 5:18:11 PM, Anders D. Johnson ([email protected])
wrote:

@LinusU https://github.com/LinusU Sounds good to me. @jimthedev
https://github.com/jimthedev shall we pursue this sort of refactor?
Want to get through any pending PRs or major upcoming changes first?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#29 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGpijNHZ8nzRQzptXkSDNS1Tjx2ukSXks5qePyjgaJpZM4JebPE
.