Document slugs of brands

[ericcornelissen]

Issue: Closes #4946, relates to #4918
Alexa rank: n/a

Checklist

• [n/a] I updated the JSON data in _data/simple-icons.json
• [n/a] I optimized the icon with SVGO or SVGOMG
• [n/a] The SVG viewbox is 0 0 24 24

Description

This adds a script to generate a MarkDown table of brand names and their respective slugs, and references this in the README.

The only thing left to do is figure out how to automatically update it. I think the best approach is it automatically update it with every release. Thoughts @simple-icons/maintainers ?

I updated the create-release.yml workflow to update the slugs table automatically with every release. This required some changes w.r.t. to the release action:

• BEFORE: the release action would create a version bump commit updating the version number of the package in package.json
• NOW: when this is merged, Don't commit version bump when creating a PR release-action#35 must be merged and then then release action will ONLY create the release PR and the create-release.yml workflow will create a commit with both a version bump and updates to the slugs table.

[ericcornelissen]

Alright, I updated the release-action workflow for creating the release PR as per my previous comment and I added the output it expected in simple-icons/release-action@dc0cc8e. If we decide to use this approach and merge this PR, we should also merge simple-icons/release-action#35 to prevent the release action from creating a version bump commit.

[ericcornelissen]

I updated the release-action workflow for creating the release PR a little more to make some further improvements - especially with regards to the edge case where no release PR is created because there are no notable changes. Hence, I added another output value that tells you whether or not a release PR has been created, see simple-icons/release-action@dad562c, which I'm using here to check if a second job should be run. If it should, the version bump commit is prepared (by updating the version in the project manifest and updating the list of slugs) and created.

You can see a test run of when no release PR is created and a test run of when a release PR was created

[ericcornelissen]

Alright, after some further tweaking I was able to get this working - I think. You can see a preview of this in this run of the create-release.yml workflow which resulted in this Pull Request being created with this version bump commit 🎉

[service-paradis]

LGTM 💯 🎉

[PeterShaggyNoble]

Should we also add something to CONTRIBUTING.md here about when and how to use slugs?

As part of that, I would suggest moving the "SVG Filename Convention" up above the "Update the JSON Data for SimpleIcons.org" section as:

1. It makes more sense within the workflow of creating an icon to tell people what to name their file after they've annotated & checked it, and,
2. They'll need to know what the filename is for the (potential) slug before adding the data to the JSON.

[ericcornelissen]

Should we also add something to CONTRIBUTING.md here about when and how to use slugs?

As part of that, I would suggest moving the "SVG Filename Convention" up above the "Update the JSON Data for SimpleIcons.org" section as:

1. It makes more sense within the workflow of creating an icon to tell people what to name their file after they've annotated & checked it, and,

2. They'll need to know what the filename is for the (potential) `slug` before adding the data to the JSON.

While I'm not against switching the order, it seems beyond the scope of this Pull Request - it currently doesn't even touch the Contributing Guidelines.

Now, when you say "how to use slugs" do you mean as a user as the package? If so, it shouldn't be in the Contributing Guidelines (which is also why I didn't edit the Contributing Guidelines, this PR is for package users, not contributors). If you mean how to use the slug property in the JSON data file, then it could be in the contributing guidelines but I thought we decided against it so as to avoid newcomers using it while they shouldn't, and instead only use it when upon request from the maintainer.

[PeterShaggyNoble]

Now, when you say "how to use slugs" do you mean as a user as the package?

No, I meant telling contributors when a slug should be added and how to construct it.

I thought we decided against it so as to avoid newcomers using it while they shouldn't

Was that not just in the context of making exceptions for filenames (which we're not 100% decide on yet)? I agree in that case we shouldn't include it in the contributing guidelines but I do think we need to at least cover how to resolve conflicts when 2 brands share the same name through the use of the [brand]_[modifier] slug.

[ericcornelissen]

Was that not just in the context of making exceptions for filenames (which we're not 100% decide on yet)? I agree in that case we shouldn't include it in the contributing guidelines but I do think we need to at least cover how to resolve conflicts when 2 brands share the same name through the use of the [brand]_[modifier] slug.

That sounds reasonable and I would support adding it. Though again, this seems out of scope for this PR to me. I can add it when I find time but it will either hold this PR back as it is, or that improvement to the contributing guidelines if this PR needs more work...

[PeterShaggyNoble]

this seems out of scope for this PR to me

Fair enough 👍🏻 I'll to get a PR together over the weekend if I've time and you don't beat me to it.

[PeterShaggyNoble]

This looks good to me now, thanks, Eric 👍🏻