thanks for letting us know. Also happy to hear that we’re addressing problems you struggled with. Let me ramble a bit, 'cause it’s sunny outside, and I attribute all my brain-stuff to hay fever.
I had a quick look at the code, and I like the idea to focus on bundle as the API you mock. Can you put multiple resource files into one bundle? I also think you handled the locale-dependent runtime right, but diving into that, I think I found a bug in
$select ;-). Also, do you handle
foo-bar as a different message from
Regarding naming, I mostly defer this to @stas, but I’d like to alert you that we’ll rename our packages into a
@fluent namespace. That said, I can’t think of something Fluent-y that I’d rather call
compiler than a code module like the one you’re working on.
What you’re doing is technically similar to the things we’re doing on the python side. There’s the
compiler branch by Luke, and also the pre-evaluating resolver on
master. It might be possible to do something similar, and then
toSource that? I wonder if one could escape out of your serializer logic with funny terms and term references and possibly string literals. Maybe relying on something like
escodegen to serialize source would be easier to make secure?
Granted, right now it’s really hard to write resolvers, 'cause there’s no specification for them, so you’re kinda bound to reverse engineer the js impl. We also don’t have extensive nor platform independent tests, which would catch things like number literals in select expression variant keys (that’s the bug I found, I think). I wouldn’t be surprised if we got a couple of changes in the resolver designs still. Like, I have a thought in the back of my mind to resolve to generators or arrays instead of strings, but that’s for another day.
Some further thoughts: I’m pretty sure that your work is a good answer to some use-cases. Similar to the work that Luke’s doing for
elm-fluent, being close to the Metal sometimes pays off. Getting these secure and reliant and being “Fluent-y” is hard, because that stuff is mostly encoded in the heads of two-three people.
Would you be up for helping us narrow down on the needs of resolver implementers on tests and specification? Like, all the questions I asked should really be test cases, I guess.
One nit on the README, it’d be “Fluent-y” to have a module on top of
fluent-compiler that does language fallback. We usually call these
Localization, for the lack of a better word to describe “the thing that iterates over bundles to find the one that has the strings for the IDs you gave, in order of negotiated locales, possibly async”. Is that part of what you’re having in mind? Might be good to hint at in the readme.