Question/help for understanding where the commit attributes come from to use on the handlebars templates

[arkadioz]

Hey @momocow thanks for your help recently, I have been trying to understand a lot of the "how it works" of all the ecosystem but it is a lot, just understanding handlerbars "logicless" syntax has been a challenge, there is something that is what is the most hard thing to understand so far and it is the "context" where do this commits and its attributes come from (ofcourse git but let me explain further)? Can not find were is that defined, I was using before your tool, this other tool with the semantic-release/commit-analyzer and also semantic-release/release-notes-generator, then I used a "preset" for the conventional-changelog called "conventional-changelog-conventionalcommits", and this preset also has some "options" or "configuration that you can do" specified here

my confussion comes when you see they have all those "substitutions" or "attributes" that they can use like for example {{commit.scope}}
in this file for example: https://github.com/conventional-changelog/conventional-changelog/blob/7ac186060b16ea66847c401d57ca78157329d778/packages/conventional-changelog-conventionalcommits/templates/template.hbs#L9

but then when I try to use that attribute {{commit.scope}} in the commit-template that we use here at semantic-release-gitmoji, it is not available, that is were I wonder why and how they have that attribute available? What is the config I am missing to be able to have those attributes, if you could clarify were is that config setup and if it is possible to configure that in the context I would really appreciate, that has been the most struggling point for me to understand what can I configure and what I cannot (ofcourse, it is not here in gitmoji because it is not configured to be in the context, but would it be possible to have it? If so how? And were in that project that it is available it was configured to be available?).

I tried using it here in the template like so (but I think it is not available):

{{#if commit.scope}}
    - Scope: {{commit.scope}}
{{/if}}

{{#if scope}}
    - Scope: {{scope}}
{{/if}}

{{#if this.scope}}
    - Scope: {{this.scope}}
{{/if}}

but that is what I want to understand why is it available over here: https://github.com/conventional-changelog/conventional-changelog/blob/7ac186060b16ea66847c401d57ca78157329d778/packages/conventional-changelog-conventionalcommits/templates/template.hbs#L9 were did they configure it to be in the "context"?

[momocow]

The first thing you should keep in mind is that there are 2 different commit formats we are talking about, says conventional commits and gitmoji commits.

Conventional commits have their grammar like this (ref)

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

while gitmoji commits have their one like this (ref)

<intention> [scope?][:?] <message>

As you can see, scope should come from commit format parsers, which is commit-analyzer for conventional commits and semantic-release-gitmoji for gitmoji commits.

Notice that I use "should" here. The reason why it is not available is because at the time I wrote this plugin there was no such concept, says scope, in gitmoji and no one ever asked for it since then (almost 6 years ago). lol

why and how they have that attribute available?

No why, scopes in conventional commits are independent from scopes in gitmoji commits.

They are both similar concepts but different specs/implementations.

What is the config I am missing to be able to have those attributes, if you could clarify were is that config setup and if it is possible to configure that in the context

would it be possible to have it? If so how?

Yes, but not in the current version but the future ones.

were did they configure it to be in the "context"?

Follow the commit format above.

For example, make a commit with the following message in convention commit format:

feat(my_scope): introduce a new feature

 issue#100

[momocow]

Frankly speaking, it was also a headache for me to trace codes that were written 6 years ago, though I'm the author. lol

As you already know, to improve user experience, there are some enhancements required to make this plugin better.

I'll think about refactoring the project recently to make it more extendable and customizable.
Though for now, it's only a plan in my mind. 🤔hmmm

[arkadioz]

@momocow Thanks for helping and explaining, I think this is a very useful tool and worth it the refactor/enhancements of those little details, I was asking this also because I wonder if maybe I needed more variables that are not available by default in the context, like how I would still have a way to include them, so far I did this just as a test and it worked (environment variable) in the .releaserc.js:

const repoName = process.env.repoName;

and then I would use it in here for example:

      [
         "@semantic-release/changelog",
         {
            "changelogFile": "docs/CHANGELOG.md",
            "changelogTitle": ['# Gitmoji Changelog', repoName, '\uD83C\uDF88'].join(' ')
         }
      ] 

Also I am not sure how to easily pass variables to the Handlebars templates or the already defined context, this is what I did to be able to have or bring that "repoName" variable to the template as an example/test, created a Helper (getRepoNameFromEnv) but if you know a better way to bring it to the hbar template I would appreciate (this one works but I am guessing this is not the best way):

            releaseNotes: {
               template,
               partials: {
                  commitTemplate
               },
               helpers: {
                  formatDate: function(date) {
                    return dateFormat(date, 'yyyy-mm-dd HH:MM:ss');
                  },
                  getRepoNameFromEnv: function(){
                  return repoName;
                  }
               },
               issueResolution: {
                  template: '{baseUrl}/{owner}/{repo}/issues/{ref}',
                  baseUrl: 'https://bitbucket.org',
                  source: 'bitbucket.org',
                  removeFromCommit: false,
                  regex: /#\d+/g
               }
            }
         }

An AI was recommending this other way to include my own variables into the Handlerbars template/context (ofcourse this did not work):

            releaseNotes: {
               template: async function(data) {
                  const compiledTemplate = Handlebars.compile(await template);
                  return compiledTemplate({repoName});
               },
               partials: {
                  commitTemplate
               },
               helpers: {
                  formatDate: function(date) {
                    return dateFormat(date, 'yyyy-mm-dd HH:MM:ss');
                  }
               }
            }

do you know how could that be done in todays app state?