Allow additional imports with natalie-imports.json

[ldiqual]

@krzyzanowskim

Here's a proposed fix for #37, as per phimage's suggestion.

This commit modifies natalie.swift so it can take a second argument imports_file_json. This JSON file must contain an array of all the framework names to import and that natalie might not be able to autodetect (see original issue).

For example, in natalie-imports.json:

["FlatUIKit"]

and then:

$ natalie.swift <path_to_project> natalie-imports.json

which will add import FlatUIKit right before custom module imports.

A couple notes:

• In a perfect world I would love natalie-imports.json to be automatically detected in projectdir, but since the documentation says that the path should be projectdir/projectname we'd have to go one directory up and that seems a bit hacky.
• Having a long argument like --additional-imports natalie-imports.json would be best, but I didn't want to add too much code without your approval (since we'd need to hack around Process.argv)

Let me know what you think about this solution and how to possibly improve it.

[phimage]

To be automatically detected in our perfect world you can put the file near the storyboard with specific extension, as I do with my PR https://github.com/krzyzanowskim/Natalie/pull/48/files
Without that XNatalie or a generic launcher will not add the additional command parameter

[krzyzanowskim]

what is wrong with specyfying module in storyboard? this is the easiest way to handle it. Configuration file introduce complication how to deal with the file, where to store etc. I'd like to realy avoid that as long as possible.

[phimage]

you can't specify module for objective-c framework, this is what I understand in the corresponding issue

[krzyzanowskim]

@phimage --additional-imports or any option would be good to have for this.

[phimage]

Yes option is far better than adding an extra argument behind the file path
But option

• break XNatalie (or need to ask options, register it by project) or other launch shortcut
• more codes and dev , except if third party command line parser is included in Natalie

I prefer configuration files by storyboard because

• Natalie generade code for multiple storyboards and each storyboard have its own issue and could be generated alone for test (and option could be forgotten)
• No need to change generic command line, launcher, etc...
• Easy to add other configuration options for other issues

that's why I make "plist" into PR #48

then plist VS json, the two are easy to read, but in Xcode I prefer create and edit plist file

[hartbit]

As a side note, if a solution is found to the issue #64 I just opened where I ask for a feature to have Natalie parse an xcodeproj file to generate target specific files, Natalie could automatically find out which frameworks each target is linked with.

[ldiqual]

@phimage I like the solution of a configuration file next to the storyboard. Not really a big fan of the plist format but at least it's consistent with what apple uses.
@hartbit Agreed that your solution would be best, maybe we could iterate by merging #48 and #64 when it's code-ready?

[krzyzanowskim]

hello, I want merge this change, can you please rebase to current codebase ? 👍
This feature need documentation in README too.