kellpossible
rust-analyzer currently broken when adding a new translation
https://github.com/kellpossible/cargo-i18n/issues/83#issuecomment-2798516265
from what is see, we need need a cache invalidation.
Perharps the FluentLanguageLoader struct could store HashMap<PathBuff, u64>, to remember all files dependencies, and the last modification date. And we can then had check to know if the files have changed or not.
Sound good @kellpossible ? I can work on this.
Also, i don't understand why here https://github.com/kellpossible/cargo-i18n/blob/659b53c45bc68b0742696bc8f53fc6cace83b11b/i18n-embed-fl/src/lib.rs#L409, we try to get the domain data only considering the package name, but after, we consider the config file https://github.com/kellpossible/cargo-i18n/blob/659b53c45bc68b0742696bc8f53fc6cace83b11b/i18n-embed-fl/src/lib.rs#L440. Sounds like a bug no ?
is this something we would be better off using https://github.com/notify-rs/notify for do you think @wiiznokes ?
I think it's probably already in use in i18n-embed if my memory serves me correctly, as an optional feature.
Yeah, i think using notify could do the trick, and it's a 10 lines fix in this case.
I think the "cleanest" solution would be to use cargo::rerun-if-changed because it would
- use cargo cache mechanism
- full error sync, even when the macro input doesn't change (with notify, the macro result will be reloaded only when the input change, which is good enough imo, but not perfect)
- cache mechanism at crate level, not a every macro call level
- we could also add the config file to reload the file when the config change
but it require the user to define an env variable...
With notify, it works out of the box. Tho, there will be a watcher instance for every macro call. I don't think it's very optimized, for a crate with 1000 macro call for example. It might be totally fine tho.
My current implementation comparing timestamps is probably more optimized, for the same result. Lmk what you think
With notify, it works out of the box. Tho, there will be a watcher instance for every macro call. I don't think it's very optimized, for a crate with 1000 macro call for example. It might be totally fine tho.
Nevermind this, i'm dumb. There will be one instance of notify per domain. So using notify is probably the best solution, i will update the pr when i can