-
-
Notifications
You must be signed in to change notification settings - Fork 617
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SourceryFramework #715
SourceryFramework #715
Conversation
…ll???) and added Yams (how was it even working before???)
Generated by 🚫 Danger |
40d2f81
to
2d77f86
Compare
I've pushed a missing change to the SPM manifest with SourceryFramework.
One solution I see would be to add a Note that the |
I've extracted the files into |
@ilyapuchka anything left to do here? |
@krzysztofzablocki I guess should be fine now with Utils framework |
@ilyapuchka you can merge then if you are happy with it 👍 |
* extract parsing and generating functionality into SourceryFramework * removed unneeded AEXML dependency (have we ever used it directly at all???) and added Yams (how was it even working before???) * removed rangeToAppendBody * Configure SourceryFramework in SPM * Extract Sha, Version and Path+Extensions into SourceryUtils
This PR introduces SourceryFramework that exposes parsing and generating functionality (generating part is really just two protocols then implemented by the tool). Motivation for that is that this framework can provide the foundation for other tools, especially parsing, which don't necessarily want to use templates and generate code, without the need to include such functionality in the tool. There were multiple requests in the past about such features which were shut down because they were considered out of the scope of Sourcery as a tool.
Mainly this change is about moving files around and changing minimum amount of internal types and properties to public to make the main tool compile. We may want to revisit public API later to expose more things publicly.