Skip to content
This repository has been archived by the owner on Feb 5, 2018. It is now read-only.

Redesign API #20

Closed
stevemao opened this issue Feb 10, 2016 · 9 comments
Closed

Redesign API #20

stevemao opened this issue Feb 10, 2016 · 9 comments

Comments

@stevemao
Copy link
Collaborator

stevemao commented Feb 10, 2016

Edit: TBH not too many people would config the API and they usually just use the default one or a preset. But if they do, they only change a small part. I believe an array of functions should solve this.

@stevemao
Copy link
Collaborator Author

In fact, it should be the other way. transform can be used for any kind of things and other options make it easier.

@stevemao
Copy link
Collaborator Author

Link conventional-changelog-archived-repos/conventional-changelog-core#4

The API should probably look something like expressjs's middleware, promise or stream pipe where you can do something else based on the previous work.

Maybe we could make transform and finalizeContext an array. For each existing option, say groupBy, could be made into a single function. and by default, there are a few functions in the array.

@stevemao stevemao changed the title We can probably just use transform and so options like groupBy is not needed? Redesign API Apr 19, 2016
@stevemao stevemao added this to the 2.0.0 milestone Apr 19, 2016
@stevemao
Copy link
Collaborator Author

stevemao commented Apr 21, 2016

compose seems to be a good fit here.

@stevemao
Copy link
Collaborator Author

stevemao commented May 2, 2016

@bcoe @nexdrew I need some suggestions here. I'm quite happy with the api of conventional-commits-parser. This one seems a bit tricky.

@silkentrance
Copy link

silkentrance commented May 3, 2016

For starters, and also considering the way for example conventional-changelog-angular works is that upon transform it will first filter and then rewrite/transform existing commits.

How about splitting the filtering and the transformation into two distinct functions, e.g.

writerOpts : {
   filter : function (commit) {...},
   transform : function (commit) {...}
}

The transform function will then only receive the commits returned by the filter and must then process all of the commits it receives. The filter on the other hand will only return a commit when it needs to be included in the changelog. That way, one can simply override the filter function... provided that the transform function will be adjusted as well.

Of course, one could think of passing additional options to the filter or even the transform function.

@stevemao
Copy link
Collaborator Author

stevemao commented May 4, 2016

@silkentrance This will still have exactly the same problem. I believe an array can completely solve this.

@kachkaev
Copy link

kachkaev commented Nov 25, 2016

I also struggled with this and finally found the reason why this is happening:

https://github.com/conventional-changelog/conventional-changelog-angular/blob/e32d954eac0766916b9b7408efed95d643a198a9/index.js#L58-L59

Looks like there is no way to tell the parser to include all types of changes into the markdown, unless overwriting the whole transform function.

Related discussion: conventional-changelog-archived-repos/conventional-changelog-angular#13

@kachkaev
Copy link

kachkaev commented Nov 25, 2016

It's a bit of a pity that there is currently no way to pass an option to Angular's transform and thus get a custom set of types in your changelog. I know that this is sort of against Angular's convention, but it can be still useful. E.g. a complete changelog can be attached to repos's tags or exported somewhere else. IMO there should even be an option to include unclassified commits for those who want this.

@hutson
Copy link

hutson commented Feb 5, 2018

We're closing this issue out as this repository has been merged into our conventional-changelog mono-repository.

If you would like to see this change incorporated into conventional-changelog please consider re-opening the issue against the conventional-changelog mono-repository.

@hutson hutson closed this as completed Feb 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants