Inline generated code

[ilyapuchka]

After watching a talk mentioned in #14 I think it will be crucial to be able to provide an option to put generated code right into source files instead of separate files. The problem is that in separate files we can not access private variables, so either parser should just ignore them (as I mentioned in #38) or generated code will not compile anyway if it uses private variables. So we will not be able to use them for example for description and other stuff. Or we must enforce user to not use private variables which is not very nice too.

To achieve that we can simply always put generated code in the end of the file and separate it from other code with annotation comment (like "// sourcery: generated"). Then user will be just required to put his own code before that section, so that we don't override it. Feels like a reasonable tradeoff.

We might need to add a command line argument to define in what mode Sourcery should work. Then user can choose what templates should be used to generate code inline and what in separate files.
There should be also a separate collection of types accessible in templates like filetypes that will contain only types defined in that file for "inline" mode.

[krzysztofzablocki]

It's an interesting option to add, but I think we have much more things to add before we should consider implementing this.

When we start to mutate original Source then I start getting a little more worried about potential implications, FWIW. you wouldn't be able to use private code in that case anyway, only fileprivate.

Once we get to more stable feature set then we can explore this feature, does that make sense?

[ilyapuchka]

Sure, not even for 1.0 maybe.

[krzysztofzablocki]

I'll probably consider how to implement this next because it would be convenient for things like NSCoding etc

[krzysztofzablocki]

How do we feel about this syntax for both code and template:

// sourcery:inline:Type.AutoCoding
// sourcery:end

It would:

• Remove the body of that generated pattern while parsing (to avoid chicken-egg problem)
• Find the same pattern in one of the template generated code
  • Replace the source code with generated code
  • [Question] Comment out or Remove the Template fragment?

[ilyapuchka]

What do you mean by "comment or remove the template fragment"? Do you mean these annotations for source code?

[krzysztofzablocki]

I wonder what should happen inside the output swift file (because there might be more code than just the inline fragments, whether we comment it out, or remove it completely when we put it inside the project source code.

e.g. currently NSCoding has commented out code, that the replacePlaceholders script uses, we won't do it like that obviously, but I wonder if having commented out code that we replace wouldn't be helpful, especially in watcher mode

[ilyapuchka]

You mean having this in template:

something else

// sourcery:inline:Type.AutoCoding
...
// sourcery:end

something else

should we remove what is generated by everything outside annotated block? I would say yes. Otherwise it may be just easier to put the name of the template in the annotation and just put everything generated by it in the source file. And in the end templates as everything else should do one thing only.
Why do you think we would need to keep it commented?

[krzysztofzablocki]

this is what I mean:
e.g. Template.stencil

some common code needed for the template

{% for type in types.implementing.AutoCoding %}
 // sourcery:inline:{{ type.name }}.NSCoding
   required init?(coder aDecoder: NSCoder) {
     ...     
   }
// sourcery:end

e.g. source code:

class Foo: NSObject, AutoCoding {
   // sourcery:inline:Foo.NSCoding
   This is where the code would be injected
  // sourcery:end
}

What happens in Template.generated.swift?

a) the code between sourcery:inline disappear completely
b) the code between sourcery:inline is commented out but there (same as injected into source)

[ilyapuchka]

Now I get it =) I would go for "a" but will maybe add a comment saying "generated code inlined in file ..."

[ghost]

Ok, just to confirm something

I use the inline approach for all of the generated code in my project.

The following file demands I have an output key.

while reading .yml 'some/path/.sourcery.yml'. 'Invalid output. 'output' key is missing or is not a string or object.'

The presence of an output key in the following file seems to generate an empty file called someName.generated.swift

sources:
  - some/path
templates:
  - some/path
output:
  ./

There is currently no option to stop this file from being generated, right?

It's not the end of the world as I can just exclude it from compile sources & git.

[ilyapuchka]

@rob-nash the output path is required, as well as sources and templates paths. The empty generated files are supposed to be removed. If not - that's a bug, you may want to create a new issue with a reproducible example.