You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was testing the latest core preview (24) and I was playing around updating strings between local and production. The sync using mfAll.js works perfectly well, but there is one caveat.
If I update some strings in my local instance and, right after, I update another string in production and then I try to update production releasing my exported mfAll.js from the local instance, the strings are never updated even though the most recent update for those strings is the one from my local instance.
Manually changing the "updatedAt" in the mfAll.js that is released to the server to be > than the updatedAt in server's collection mfMeta makes the updates finally trigger in the server.
This is true, of course, for the reverse server2client update as well.
I believe the culprit should be this line and the ones preceding that.
Not sure if there's a more compelling reason that I didn't fully understand why the global updatedAt check prevents the update altogether, even though there are strings that should be updated.
Off the top of my head, maybe the rationale is to avoid expensive string-by-string check that take time and might not be successful?
Or is there something else that I didn't consider to actually sync between local and production?
The text was updated successfully, but these errors were encountered:
Hi and kudos for this amazing package!
I was testing the latest core preview (24) and I was playing around updating strings between local and production. The sync using mfAll.js works perfectly well, but there is one caveat.
If I update some strings in my local instance and, right after, I update another string in production and then I try to update production releasing my exported mfAll.js from the local instance, the strings are never updated even though the most recent update for those strings is the one from my local instance.
Manually changing the "updatedAt" in the mfAll.js that is released to the server to be > than the updatedAt in server's collection mfMeta makes the updates finally trigger in the server.
This is true, of course, for the reverse server2client update as well.
I believe the culprit should be this line and the ones preceding that.
meteor-messageformat/packages/core/lib/msgfmt-server.js
Line 40 in 7b1c8af
Not sure if there's a more compelling reason that I didn't fully understand why the global updatedAt check prevents the update altogether, even though there are strings that should be updated.
Off the top of my head, maybe the rationale is to avoid expensive string-by-string check that take time and might not be successful?
Or is there something else that I didn't consider to actually sync between local and production?
The text was updated successfully, but these errors were encountered: