Sam A. Horvath-Hunt
Sam A. Horvath-Hunt
Off the back of #114/#115, it'd be great to have more lines/context around errors. Example: ``` ./x-all.json:6:21: | 6 | "message": "{x, bad}" | ^^^^^^ unexpected "bad}" }, " expecting...
Looking at the lints reference: https://github.com/unsplash/intlc/wiki/Lint-rules-reference#duplicate-select-case This is theoretically doable in some cases as a code transformation. The hidden challenge is that the user's formatting would need to be preserved...
e.g. if the same number is used twice we'll compile two instantiations of `Intl.NumberFormat`. The compiler knows enough to potentially open a function body and declare a variable.
Possible syntax that wouldn't diverge too much from ICU: ``` {input, newtype, NewtypeName, string} ``` I don't know how this could be implemented in languages that support newtypes natively. Likewise...
Some context: https://github.com/unsplash/intlc/issues/102#issuecomment-1089919665
This could be something fun to explore: https://serokell.io/blog/parser-combinators-in-haskell#bonus%3A-quasi-quotations ```hs [icu|Hello {name}|] ``` Might be helpful for testing stuff like flattening where ideally we could supply a known valid message without...
We currently support a superset of ICU that includes `boolean`, doesn't always require `other`, etc. We could compile this down to something ICU-compliant for better interop with other tools. The...
https://github.com/tc39/proposal-intl-messageformat A ways off, but something we should potentially support in the future. intlc will likely still provide a superior experience than plain JS/TS as with ICU especially for type...
There's a potential React hydration mismatch between timezones on server and client on web anywhere we're using a `date` or `time` type. This is because `Intl.DateTimeFormat` uses the system timezone...
At the moment we iterate through the AST anew for each rule. This is slow, although it's not perceptible for our use case yet.