Skip to content
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

Closed
pkozlowski-opensource opened this issue Aug 15, 2014 · 14 comments
Closed

Split up this repo into commits parsing and writing #22

pkozlowski-opensource opened this issue Aug 15, 2014 · 14 comments

Comments

@pkozlowski-opensource
Copy link

@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.:

  • figure out next semver based on the commit names
  • use completely different writing format / target (I think GH releases were mentioned).

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.

@ajoslin
Copy link
Contributor

ajoslin commented Aug 24, 2014

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.

@brunowego
Copy link

+1

@stevemao
Copy link
Member

I'm working on this issue. I feel it's very hard to maintain/test now if they are not broken into smaller pieces.

@pkozlowski-opensource
Copy link
Author

Great @stevemao !

@stevemao
Copy link
Member

stevemao commented Mar 2, 2015

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 lodash.template string? And because in https://github.com/stevemao/conventional-commits-parser I can get any part of a commit so this way it will be very flexible but a lodash.template string is pretty hard to construct especially one with if statements and nested loops, etc (I have problems making a default one but I think I can make it eventually). Or we can expose something like

{
  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 lodash.template is hard to use especially if there are too many if statements or nested loops. May be I should use something else?

@ajoslin
Copy link
Contributor

ajoslin commented Mar 3, 2015

@stevemao maybe it would be best to use a nunjucks template or similar to render the whole changelog... example:

{% block header %}
{{"###" if bump.patch else "##"}} {{title}} {{subtitle}} {{version}}
{% endblock %}

{% block body %}
{% for section in sections %}
#### {{section.name}}

{% for subject in section.subjects %}
{% block subject %}

{% set prefix = "\n  *" if subject.commits.length > 1 else "" %}

* **{{subject.name}}*: {% for commit in subject.commits -%} 

  {{prefix}} {{commit.subject}} ({% block commitLink -%}
    {% if repository -%} [{{commit.shortHash}}]({{repository}}) {% else %} {{commit.shortHash}} {% endif %}
  {%- endblock %}{% if commit.closes -%}
    {% for issue in commit.closes -%}
      {% set prefix = " " if loop.first else ", " %}
      {% block issueLink -%}
        {{prefix}}{% if repository -%}[#{{issue}}]({{repository}}/issues/{{issue}}){% else %}#{{issue}}{% endif %}
      {%- endblock %}
    {%- endfor %}
  {%- endif %})

  {# breaking change text #}
  {% if commit.body %}<br>{{commit.body}}{% endif %}

{%- endfor %} {# END COMMITS IN SUBJECT #}

{% endblock %} {# END SUBJECT BLOCK #}
{% endfor %}

Then people could overwrite the whole changelog template, or just bits and pieces by overriding the different blocks (eg block commitLink). Thoughts?

@stevemao
Copy link
Member

stevemao commented Mar 3, 2015

This looks beautiful, will dig into nunjucks 😄

Thanks @ajoslin!!

@stevemao
Copy link
Member

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.

@ajoslin
Copy link
Contributor

ajoslin commented Mar 26, 2015

Awesome, steve. Looks perfect.

@stevemao
Copy link
Member

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...

@ajoslin
Copy link
Contributor

ajoslin commented Mar 26, 2015

I mean the concept of everything that's going on looks perfect. Everything is modular, 100% customizable, and 100% pluggable.

@rauno56
Copy link

rauno56 commented Apr 16, 2015

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?

@stevemao
Copy link
Member

#51

@stevemao
Copy link
Member

Please checkout the rewrite on the master branch. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants