Let’s flesh out the idea before starting to code. I’m still unsure that it should be part of Refined GitHub, especially at this length. Most features are very short or very useful. Currently this is neither

Thanks, I understand the concern. I have been verbose with the code and created many readable code blocks and functions to keep it simple. It is possible to half the code size probably at a similar length like other features at the cost of a bit of readability

I only now saw the video. I kind like it actually, better than the original mockup. Potentially this also voids what I said about the non-semrel fix keyword since its visual position is preserved on the commit title line.

You can continue iterating

• Display labels instantly (Help needed from maintainers)

Look into the observe function and drop awaitDomReady

• Render everywhere where commits are shown pageDetect.isRepoCommitList for some reason doesn't work (Help needed from maintainers)

isCommitList already includes that.

Now the next question is: should this only apply to commit lists? How about single commits? How about PRs (this exact page, not the commit list)? I’m afraid that colors and bubbles might be noisy or “ugly” there.

• Render when clicking on "Next" or "Previous" in the commit list instead of refreshing (and similar actions) (Help needed from maintainers)

The observe function suggested above helps.

• Implement missing default commit types

If this is merged, we should only support the official keywords and format as defined by the official documentation.

• Add options to specify color, custom commit types , to hide the scope and display the label before or after the commit message

No options allowed in Refined GitHub, see:

https://github.com/refined-github/refined-github/wiki/%22Can-you-add-this-feature%3F%22#3-it-doesnt-require-options

I want to include “semantic release” in the feature name. How about this one?

By the way let’s merge this feature “as is” before attempting to add more features, like skip-ci detection etc.

If this is merged, we should only support the official keywords and format as defined by the official documentation.

Semantic release uses the angular commit convention by default, specifying a handful of commit types. These should be the defaults.

No options allowed in Refined GitHub, see:

It says "required". No options are "required". "required" options mean for example an API key for a feature to function. The options I suggest are not required but good to have and probably should be added because while semantic release uses angular commit conventions by default, people conventionally use "chore" for example. semantic-release itself does it too but its not specified in the angular commit convention. Additionally, semantic release allows using custom commit types.

I want to include “semantic release” in the feature name. How about this one?

Thanks for the recommendation. How about "render-semantic-release-commits"? This implies that it is commit related, semantic-release related as well as rendering related. "render-semantic-release-commit-types" would be even better because it also mentions that the types will be rendered. Let me know what you think.

No options allowed in Refined GitHub, see:

It says "required". No options are "required". "required" options mean for example an API key for a feature to function.

I wrote the document, it means no options period. You can check the feature list and you’ll find no per-feature option. This is non-debatable.

You can read that as: is this feature still useful without options (because we do not add options)? Then we can add the feature.

If it’s only useful with options (i.e. “it requires options to meaningfully exist”) then we won’t add it here, it can be published as its own extension/userscript, not everything needs to be part of Refined GitHub.

In that case, the default types should be extended to other common types that everyone uses. Remember that if you do not use them in your project, the feature will still work as expected. It will render the types you use, but for those that use the other common types, it will also render. Semantic release itself already uses "chore," which isn't in the angular conventional commits spec.

Here are the current colors

Let’s focus on the functionality for now. Colors can actually be customized by the user via class name so they’re minor. I’d expect them to be colorless by default except for the standard bug/enhancement/documentation label colors that GitHub natively offers.

By the way let’s merge this feature “as is” before attempting to add more features, like skip-ci detection etc.

This was not part of the issue, I had it in the screenshot accidentally 👍

Let’s focus on the functionality for now. Colors can actually be customized by the user via class name so they’re minor. I’d expect them to be colorless by default except for the standard bug/enhancement/documentation label colors that GitHub natively offers.

I am already done with all reviews except one you wanted to take over (I don't know how to implement it anyways).
Here is what it would look like colorless:

And here with colors:

I think most people that use the extension will not change anything let alone the CSS. They will see the badges and be annoyed they are colored the same way, so I think a default color is better than nothing. Less people will be annoyed, and those who are can change it via the CSS.

I can not pass a test, but I am unsure why (It seems like a silly skill issue on my end). Other than that ready for review one more time.

Did you run npm run fix

Did you run npm run fix

It removes the screenshot in the snapshot and also throws an error because the image link is not supported by the check: https://github.com/user-attachments/assets/739264d7-b4b2-425d-91bb-d91c42c1ab21. I do not know where to upload the image to on GitHub to pass the check (it needs a .png suffix).

npm run fix is not optional, editing snapshot files manually isn’t useful.

Set that URL in the readme and then I’ll look into supporting that format in the tests.

Edit: actually you can add one more regex here:

I think /user-attachments[/]assets[/]/

Can you post a screenshot of the other page too? I’ve only been seeing the repo commit list page.

Just attach it to a comment and I’ll merge the PR

For the record, after merge these are the changes I’ll want to explore:

• use pastel colors for all
• only place the type in the bubble: (Chore) release: v1.2.3

This should help make the feature appear less disruptive/flashy. I’ll also:

• create a commit list with all the types in the sandbox repo so it can be used as a complete test URL
• apply some of the changes I mentioned earlier (e.g. change the output of the parser function, update the tests to follow Vitest patterns)
• fix the test error messages to advise users on how to deal with failures

Can you post a screenshot of the other page too? I’ve only been seeing the repo commit list page.

Just attach it to a comment and I’ll merge the PR

use pastel colors for all

I think using the default GitHub colors makes sense in terms of it blending in with the design style. Pastel colors can look nice and maybe better but would stop blending in with GitHub's design.

only place the type in the bubble: (Chore) release: v1.2.3

This reminds me of your good argument about not modifying commit messages. Rearranging words deviates further from the original message. Currently, we only remove brackets and colons, which serve syntactic purposes, without significantly altering the core of the commit message.

Your suggestion to move the 'scope' (not the 'type') to the front raises a question: why prioritize something less semantically valuable over something more? Scopes are typically used in large-scale scenarios to categorize commits by areas like frontend, backend, or modules or functions:

However, the commit type addresses the commit message directly and should be kept semantically prioritized in front of the commit scope

create a commit list with all the types in the sandbox repo so it can be used as a complete test URL

I would've liked to be able to specify a mapping from commit type to color in refined-github. This way the user would be able to use their own conventional types. semantic-release allows this for example. Also:

But I understand the design of refined-github.

Other than that, this PR has a green light from me too :) thanks for the reviews.

Rearranging words deviates further from the original message.

Does it? I suggested that style because that’s how they appear to be rendered in the release notes.

fix(player): pause on click

is turned into

Bugfixes

• player: pause on click

So, why do you think that Fix: commit was skipped in your case? Do I need to make the regex case-insensitive?

Rearranging words deviates further from the original message.

Does it? I suggested that style because that’s how they appear to be rendered in the release notes.

fix(player): pause on click

is turned into

Bugfixes

• player: pause on click

I'd say it makes sense in the context of a changelog. I misunderstood one thing you said which is to only render the type as a label and keep the scope in the commit message. I'd prefer to keep the scope in the label as the scope is metainfo which GitHub has intended labels for (Primer for example mentions that labels can be suffixed with a colon and additional information which is a perfect use case for the scope). The actual message is then presented as the commit title proceeding the commit type and scope, which is meta information to the commit message.

So, why do you think that Fix: commit was skipped in your case? Do I need to make the regex case-insensitive?

Commit types should be lowercase. I don't remember if there's a specification for that but I've not seen anyone uppercase it. What you saw in the recording was a feature branch that would've been squashed into a single commit, so we didn't pay much attention to the commit messages there and uppercased the commit type. If the spec does not mention casing for the commit type, technically as long as you are consistent with it, all casing combinations for the commit type should work. The spec mentions to be consistent though with casing referring to the beginning of the commit message after the colon.

Thanks for merging