Hi, hope you're doing well @dbanksdesign!
I noticed that because the cti/name/kebab-case transform uses lodash's kebabCase under the hood, it is prone to inserting dashes between numbers and letters as if they were different words. This is inherent in their implementation of kebab and does not appear to be up for changing any time soon.
Issues raised in lodash's repo here asking similar questions:
https://github.com/lodash/lodash/issues/2425
https://github.com/lodash/lodash/issues/4462
https://github.com/lodash/lodash/issues/4205
https://github.com/lodash/lodash/issues/4141
Here's an example of what is happening in our dictionary:
Where the json is:
"size": {
"spacing": {
"2xl": { "value": "2.5" }
}
}
Our expectation for a css variable is --size-spacing-2xl
The actual output is --size-spacing-2-xl
I understand this is probably by design, but unfortunately it creates inconsistencies between css/scss variable outputs and js/json outputs, where the resulting objects still have the original non-kebab attribute.
We have already solved this with a custom transform on our dictionary but I thought it was worth bringing up to see if you'd be open to a PR to change the default kebab transforms. Let me know if there's a reason that this should not be changed as we are ok with the custom transform, but perhaps it's worth bringing up in the docs somewhere. (Perhaps it's already in the docs and I missed it)
All the best!
Good catch! This is brought up in another issue as well: #300. I think it would be a good idea to migrate off lodash's string methods to get the behavior we want. I think this would be a good addition. We have a 3.0 branch for the next major release of style dictionary so this would make sense to go in there as it is a breaking change. If you'd like, please open a PR on the 3.0 branch and we can get this in!
Good catch! This is brought up in another issue as well: #300. I think it would be a good idea to migrate off lodash's string methods to get the behavior we want. I think this would be a good addition. We have a 3.0 branch for the next major release of style dictionary so this would make sense to go in there as it is a breaking change. If you'd like, please open a PR on the 3.0 branch and we can get this in!
Will do, thanks for the quick response!
Hi @juanfabrega !
I was getting around to checking on this as part of our 3.0 work. If you have a copy of your custom transform, I'd love to borrow it to see if it might be useable to solve this as part of 3.0
Thanks!
@juanfabrega
We are changing our case-changing support in 3.0 to use change-case and want to create some unit tests around it. If you have any challenging ones, please submit them on #500
This should now be fixed in the latest release candidate of 3.0 thanks to @chazzmoney ! You can get it with npm install style-dictionary@next
3.0 is launched! This should be fixed now!
Most helpful comment
@juanfabrega
We are changing our case-changing support in 3.0 to use change-case and want to create some unit tests around it. If you have any challenging ones, please submit them on #500