Just getting started, and wondering - can I stuff a bunch of mock data in a FTL for integration tests and things, and know that when the app is built, only the keys that are actually used will be bundled into the binary (in my case, WASM)?
Perhaps “treeshake” is the wrong word here, but I hope the use-case is clear 
Hi!
I think I understand what you’re asking about. Fluent core intentionally does not deal with I/O, and we don’t bundle your resources for you. This is the role of a higher level bindings and layers that may do that.
In result at least that level of “treeshaking” is definitely not present - if you have 10 FTL files in your package and use only three, we will do nothing about how you package them or which ones you package.
The second “layer” would be - can you select subset of resources to be loaded (I/O), parsed, stored in memory? Yes.
We encourage you to divide your messages among different FTL files, like “debug.ftl”, “main.ftl”, “extension.ftl” etc. and then you can only load the ones you need. In production you may never need debug.ftl, and in some model you may not need extension.ftl.
I’d like to point out that fluent-rs is currently fairly low level and higher level wrappers such as i18n-embed or similar higher level API.
If you don’t, you’ll want to handle the bindings and I/O by yourself and then it’s up to you how you shake and package
The package elm-fluent is implemented in such a way that it compiles FTL messages to Elm functions, which will eventually be compiled to Javascript functions. These should be very easy to “tree shake” using normal Javascript techniques. This is a very different approach to fluent-rs from what I understand.
I think what we’ll end up doing is have a separate layer of like a dashboard or something, define the fluent keys/values in there, and then have a UI option to select which bundle it goes in. Or something like that. Turns out we also need more metadata that is better solved that way than stuffing it into comments, so two birds with one stone
Thanks!
@spookylukey - hmm that is interesting. Can messages be totally isolated from the resource like that? e.g. packaged and distributed in npm without adding the bloat of other messages in the resource?