[Question] How to deal with resources/localization keys?

[acecilia]

Hi:

In order to get compile time checks on the resources and localization files used in my app, I do the following: 1- I create a standalone library called Resources. 2- I use SwiftGen to populate that library with a binary representation of the resources of the app App1. 3- At this point I use Resources as a dependency of other libraries to safely retrieve resources or localized strings.

The folder structure + dependency graph is as follows:

- App1
  * Depends on: //OtherLibraries/OtherLibrary1
  |
  |- Resources

- OtherLibraries
  |
  |- OtherLibrary1
     * Depends on: //App1/Resources

The problem comes when adding a second app to the repository:

- App1
  * Depends on: //OtherLibraries/OtherLibrary1
  |
  |- Resources

- App2
  * Depends on: //OtherLibraries/OtherLibrary1 <-- Here the Resources library that is being used is the one under App1, and this is wrong: it should be the one under App2
  |
  |- Resources

- OtherLibraries
  |
  |- OtherLibrary1
     * Depends on: //App1/Resources

The way this is done in Xcode is by using implicit dependencies inside the Xcode projects that get resolved when that project is inside a workspace (https://github.com/yonaskolb/XcodeGen/issues/224#issuecomment-359162104).

Is there any way to work around this problem in Buck? For example:

• By somehow inject the location of the Resources dependency to OtherLibrary1?
• By not fully specifying the location of the Resources library in OtherLibrary1, and letting App1 and App2 rules control it?
• By having a unique Resources library that depends on a genrule in charge of generating the code from the resources? But, in this case, how to tell the genrule which app resources to use during code generation?
• Any other completely different way that enables compile time safety on resources and lozalization files?

Thanks!

PD: I tried joining the slack channel in order to post this question, but I couldn't because it's limited to employees of specific companies, so I decided to open this issue.