This is nice because it means we've got a consistent slug on each object which is discoverable from the simpleicons website/repository/library. Adopting this would be easier for users because our slugs would match the ones used elsewhere.
However there's a downside:
The downside is that the slugs we've generated in the past are quite different for a lot of icons, so just switching from key.toLowerCase().replace(/ /g, '-') to simpleIcons[key].slug would break a lot of badges in the wild. This is a rough diff between our slugs and theirs:
This is a rough diff between our slugs and theirs:
I think it's worth making this leap, as it ultimately will resolve the recurring issue: #3639 #3297 #2980, and preferable to refining our current approach (as initially proposed in #3641).
We need a plan for how to handle the deprecation. We got some feedback in #3635 about how we handled the last one (which I realize I've yet to take the time to respond to 🙈). Overall I think it's not in our mission to keep features forever, just so people don't need to adapt or update their badges, and some amount of steering people to new endpoints and parameters is okay. But lots of people are likely to find out about these changes only through the broken badges… and I don't know exactly how to prevent that (or to make it better).
In the short term we could produce an up-to-date diff and then hard-code aliases; I'm fine deferring to another day the rest of the deprecation plan.
As a side note, I'm also a fan of failing loudly when a parameter is wrong, which is never something we've done with logos or any of the other query parameters.
Based on our request at simple-icons/simple-icons#1362 and simple-icons/simple-icons#1520, simple-icons is now shipping a canonical slug to go with each icon. As @chris48s put it in https://github.com/badges/shields/pull/3641#issuecomment-520064227:
However there's a downside:
I think it's worth making this leap, as it ultimately will resolve the recurring issue: #3639 #3297 #2980, and preferable to refining our current approach (as initially proposed in #3641).
We need a plan for how to handle the deprecation. We got some feedback in #3635 about how we handled the last one (which I realize I've yet to take the time to respond to 🙈). Overall I think it's not in our mission to keep features forever, just so people don't need to adapt or update their badges, and some amount of steering people to new endpoints and parameters is okay. But lots of people are likely to find out about these changes only through the broken badges… and I don't know exactly how to prevent that (or to make it better).
In the short term we could produce an up-to-date diff and then hard-code aliases; I'm fine deferring to another day the rest of the deprecation plan.
As a side note, I'm also a fan of failing loudly when a parameter is wrong, which is never something we've done with logos or any of the other query parameters.