-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split up this repo into commits parsing and writing #22
Comments
This sounds like a good idea. I don't know when I'll be able to get to it but I'll keep it in mind. If you wish to start splitting things Pawel, please go for it. |
+1 |
I'm working on this issue. I feel it's very hard to maintain/test now if they are not broken into smaller pieces. |
Great @stevemao ! |
Thanks @pkozlowski-opensource , I have done https://github.com/stevemao/git-raw-commits and https://github.com/stevemao/conventional-commits-parser and I'm trying to do a writer. Those modules are pretty much based on this one but I added some other features. Please make comments/suggestions on these modules. I have problems making the writer. I want the templating system of the writer as flexible as possible. Should I expose a {
headerTemplate: '...',
closingIssueTemplate: '...',
bodyTemplate: '...',
footerTemplate: '...'
} This way it is very similar to the current implementation and just expose the template. But things like loops cannot be defined by users. I think |
@stevemao maybe it would be best to use a nunjucks template or similar to render the whole changelog... example:
Then people could overwrite the whole changelog template, or just bits and pieces by overriding the different blocks (eg block commitLink). Thoughts? |
This looks beautiful, will dig into nunjucks 😄 Thanks @ajoslin!! |
I've finished the last module https://github.com/stevemao/conventional-commits-template. It's based on handlebarjs. Will put together these modules. Please have a look when you can. Thanks. |
Awesome, steve. Looks perfect. |
Thank you @ajoslin , there are a few things I wanna do. eg: make the options more flexible and improve/modify the defaults etc... still a long way to go before they are perfect... |
I mean the concept of everything that's going on looks perfect. Everything is modular, 100% customizable, and 100% pluggable. |
How's it coming @stevemao? I just discovered that support for bitbucket(different commit link. "commits" vs "commit")-Jira(non-numerical issue keys. "DEV-123")-combination could be better and was pleased to see that you are dealing with breaking up the module which would make adding the support more easy. Is there anything I could maybe help with? |
Please checkout the rewrite on the master branch. Thanks. |
@ajoslin I'm working on several build-related topics atm and can see number of use-cases where I could use just the git-related part, ex.:
In short: IMO splitting up the repo into 2 distinct parts would make each part more useful and easier to maintain. The interface between 2 parts would be output generated by git parsing.
I can surely just require
lib/git.js
from this repo (might break without warning) or just fork the whole thing (not so great for the community / ecosystem) but yeh, I feel like the sum of parts could be greater than the combined thing. WDYT? I know you are busy on other topics but I will need this type of think so willing to put some effort into it.The text was updated successfully, but these errors were encountered: