First of all, thanks for taking the time to contribute! This project can only grow and live by your countless contributions. To keep this project maintable we developed some guidelines for contributions.
devicon.json
Here is an overview of what you have to do to submit your icons to the repo.
/icons
devicon.json
to include the new icon new icon: {{logoName}} ({{versions}})
Each icon can come in different versions. So far, we have:
It is not mandatory to have 6 versions for each icon. An icon can only have one or two versions available. Just keep in mind that the minimum is 1 and the maximum 6 (for now). You must also have at least one version that can be make into an icon.
The plain and line versions (with or without wordmark) are designed to be available in the final icon font.
The original version are only available in svg format, so they do not need to be as simple and can contain numerous colors.
Some icons are really simple (like the Apple one), so the original version can be used as the plain version and as the icon font. In this case, you'll only need to make only one of the version (either "original" or "plain"). You can then add an alias in the devicon.json
so they can be found with either the "original" or "plain" naming convention.
Before you submit your logos/svgs, please ensure that they meet the following standard:
icons
folder.eps
file and as many .svg
files as versions available.eps
file contains all available versions of an icon. Each version is contained in a 128px by 128px artboard.svg
file contains one version of an icon in a 0 0 128 128
viewbox(icon name)-(original|plain|line)-(wordmark)
devicon.json
Before you open a PR into Devicon, you'd have to update the devicon.json
. This is essential for our build script to work and to document your work.
Here is the object that each of your logo must have:
{
"name": string, // the official name of the technology. Must be lower case, no space or use the dash '-' character.
"tags": string[], // list of tags relating to the technology for search purpose
"versions": {
"svg": VersionString[], // list the svgs that you have
"font": VersionString[] // list the fonts acceptable versions that you have
},
"color": string, // the main color of the logo. Only track 1 color
"aliases": AliasObj[] // keeps track of the aliases
}
Here is the AliasObj interface:
{
"base": VersionString, // the base version
"alias": VersionString // the alias version that's similar to the base version
}
Here is what VersionString means:
As an example, let's assume you have created the svgs for Amazon Web Services and Redhat logos.
For the Amazon Web Services svgs, you have the following versions: "original", "original-wordmark", "plain-wordmark". However, the "original" version is simple enough to be a "plain" version as well. Note that we are not using the acronym AWS.
For the Redhat svg, you have the "original", "original-wordmark", "plain", "plain-wordmark" versions.
/icons
amazonwebservices
and one for redhat
devicon.json
to include the icon (or variations)
amazonwebservices
, you would do this
{
"name": "amazonwebservices",
"tags": [
"cloud",
"hosting",
"server"
],
"versions": {
"svg": [ // here are the versions that are available in svgs
"original",
"original-wordmark",
"plain-wordmark"
],
"font": [ // here are the versions that will be used to create icons
"original", // original is simple enough to be used as plain
"plain-wordmark",
]
},
"color": "#F7A80D", // note the '#' character
"aliases": [
{
"base": "original", // here is the base version aka the one that we will upload to Icomoon
"alias": "plain" // this is its alias. Our script will create a reference so we can search using "original" or "plain"
}
]
}
redhat
, you would do this
{
"name": "redhat",
"tags": [
"server",
"linux"
],
"versions": {
"svg": [
"original",
"original-wordmark",
"plain",
"plain-wordmark"
],
"font": [
"plain",
"plain-wordmark"
]
},
"color": "#e93442",
"aliases": [] // no aliases
},
When you want to request a new icon please feel free to create a issue following some simple guidelines:
To make adding icons easier for repo maintainers, we rely on GitHub Actions, Python, Selenium, and Gulp to automate our tasks.
So far, the tasks that we have automated are: