gadicc / meteor-messageformat

MessageFormat i18n support for Meteor, with reactive templates
54 stars 22 forks source link

Update should not be aborted looking at mfAll.js global updatedAt #266

Open merio opened 7 years ago

merio commented 7 years ago

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.

https://github.com/gadicc/meteor-messageformat/blob/7b1c8af456a7d1c0b7839c4752f1e029d7b08102/packages/core/lib/msgfmt-server.js#L40

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?