style-dictionary
style-dictionary copied to clipboard
amzn
Error on token collision
I've seen a few tickets where users want to silence collision warnings. I'd like to do the opposite: Turn them into errors and fail the build. Is this on the roadmap, or would you accept a PR?
Hi!
We had not considered the vast array of different error handling situations; we would love a suggestion on how best to support a range of desired behaviors on error states - a PR would be most welcome!
I wouldn’t want to mess with the generally unopinionated architecture, but maybe a strict mode where some of the cations are enforced or general opt in. The two that come to mind are collision warnings and remembering to suffix references with .value. But both of those are at time desirable, so how about platform-scopes options to error?
If this approach works, I can make a PR
On Aug 29, 2021, at 11:20 PM, Charles Dorner @.***> wrote:
Hi!
We had not considered the vast array of different error handling situations; we would love a suggestion on how best to support a range of desired behaviors on error states - a PR would be most welcome!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Sorry for the delay here, but I've been pondering this a bit with @dbanksdesign .
There are three "scopes" that SD is in during processing: everything, platform, and file. There are three "settings" that any error should be able to have: ignore, warn, fail. There are several different kinds of errors in SD, most of them listed in https://github.com/amzn/style-dictionary/blob/main/lib/utils/groupMessages.js
It seems like maybe we should have a specific configuration for each error type... (and maybe an "all errors")? This would be able to be set at each scope in the config, with each more specific level overwriting the choices of the more general level. Each error would then be handled as configured. Defaults would be "warn" for all errors.
Do you think this would enable you to meet your needs? Do you think it remains unopinionated?
Thanks for your thoughts!
@goodmorninggoaway sorry for the slow response here - have been slammed with some other work.
Would you be up for submitting a PR that went this direction? Happy to support your work on this however I can
@goodmorninggoaway Are you thinking about a PR here still? We would definitely love to have it - even a really bad v0.0.1 would be appreciated!
Would also like to filter out warning messages.
We output multiple files with these in, so the reference not being available is fine.
