Sync crashes if the contentful output does not contain default locale data

[sebastianludwig]

Our output only contains de_DE data. That leads to the assertion assert(mapping.count > 0, "Empty mapping for \(type)") in ContentfulSynchronizer.swift:165 in create(_:fields:type:mapping) to fail.

In the create methods the ContentfulSynchronizer calls deriveMapping with foo.fields.keys. foo.fields takes the fields set from the localizedFields map that's mapped to the "current locale", or the defaultLocale as fallback (see Contentful/Assets.swift or Entry.swift).

The "current locale" is saved on the json NSDictionary (Client.swift:164). But not as additional entry or anything, but using objc_setAssociatedObject (in Decoding.swift). When tried to be retrieved in determineDefaultLocale it's not there anymore.

The bug comes down to Client.swift:166:

(lldb) po (json as! NSDictionary).client
▿ Optional<Client>
  ▿ some : <Client: 0x6000000b9020>

(lldb) po ((json as! [String: Any]) as! NSDictionary).client
nil

p.s. personal opinion: objc_setAssociatedObject is almost never a good idea and should be avoided.

[sebastianludwig]

This is closely related to #65

[loudmouth]

Thanks @sebastianludwig . The objc_setAssociatedObject has been on my radar for a while now as I agree with you—I prefer to avoid Objective-C runtime manipulations and I think the code could be structured with a more functional approach for locales that would use simple old dependency injection. I'll be fixing this ASAP.

[sebastianludwig]

I do have a fix in mind: Should be pretty straight forward to add the client locale to the Map object. Still struggeling to get the dev env set up...

Currently in a meeting, will get back to you asap