conventional-changelog / conventional-changelog-config-spec

a spec describing the config options supported by conventional-config for upstream tooling
109 stars 32 forks source link

publish to npm #7

Closed bcoe closed 5 years ago

bcoe commented 5 years ago

@jbottigliero here's a thought I have for configuring standard-version (and potentially other tools).

What if we publish this spec as an npm module, and index.js is just the schema with default values for everything:

{
 "types": [
    { "type": "feat", "section": "Features"},
    { "type": "fix", "section": "Bug Fixes"},
    { "type": "test", "section": "Tests"},
    { "type": "build", "section": "Build System"},
    { "type": "ci", "hidden": true}
],
commitUrlFormat: ""
// and so on.
}

Then we can pull conventional-changelog-config-spec in as a dependency for standard-version and use it to decide which configuration options need to be passed along to dependencies -- it also allows us to populate default values for all the options.

bcoe commented 5 years ago

actually, thinking about how I'd like to consume this information, it would be pretty nice if we had:

  "types: {
     "description": "what types of commit messages are shown in CHANGELOG",
      defaultValue: [
        { "type": "feat", "section": "Features"},
        { "type": "fix", "section": "Bug Fixes"},
       { "type": "test", "section": "Tests"},
       { "type": "build", "section": "Build System"},
       { "type": "ci", "hidden": true}
      ]
  }
}

then someone could use the conventional-changelog-config-spec to populate a command line builder like yargs.

cspotcode commented 5 years ago

If you include the schema as a JSON file (as opposed to .js) at a public URL, people can add the following to their config and get editor support: "$schema": "https://unpkg.com/conventional-changelog-config-spec@latest/spec.json" The JSON schema will include "description" and "default" fields as well.

You can also support tooling for JS API consumers via declaration files. You can write the spec as declaration files and extract the JSON schema from there, or vice versa. For example. Either way, you can write the spec once and include both in the published conventional-changelog-config-spec.

You can also extract an even simpler format from the JSON schema, something like export const simplerSchemaFormat = simplify(schema.properties); with whatever you want, though the JSON schema looks pretty straightforward as-is.

jbottigliero commented 5 years ago

[@cspotcode 👍 – I'm going to work on adding the spec using the JSON Schema format. I think the benefit of being able to rely on the tooling in that ecosystem will be great for keeping things in sync. Thanks for the input!

I'll put a PR together soon!

bcoe commented 5 years ago

@jbottigliero trust your opinion on the topic; my upstream requirement is ideally being able to populate yargs defaults, descriptions, and types from the JSON.

jbottigliero commented 5 years ago

Closed a bit prematurely, since it's not actually published yet.

Just opened up a PR (#9) that makes some final tweaks to the package.json before publishing to the registry.

jbottigliero commented 5 years ago

Alright, the conventional-changelog-config-spec should now be available via npm.

I have a few follow-up PRs and issues I want to open here, but this should unblock work in other conventional-changelog projects!

bcoe commented 5 years ago

@jbottigliero awesome work \o/ I'll start working on getting this update added to standard-version ASAP.

Heru788 commented 3 years ago

Good luck @cspotcode

Heru788 commented 3 years ago

Good luck