Move Gulp Templating Logic to separate repository

[srsgores]

I'm pretty sure the logic in templates/gulp/_build.js belongs in its own repo, just as does the grunt file editor. This would be useful for authors who are interested in customizing a gulp file in a new generator, but are not interested in simply copy-pasting from the source code in this repository, and could also benefit from community updates via NPM.

[zckrs]

:+1: I like this idea. Maybe we should create a external yeoman generator generator-gulp-workflow

[Swiip]

I imagined this when I seen the grunt file editor appeared. But it's a lot of work :)

As Grunt is configuration focused, it seems simpler than for Gulp which is code focused.

I don't know how grunt file editor is implemented but I imagined that it's more a full editor than a "template" which is more ambitious than what we've got already.

But yes, of course, that could be awesome :+1: !

[Swiip]

I thought a lot at this question recently, we've got several issues recently which points back to this.

Our current design choice is to break the tradition of front end MVC pattern in order to have more explicit templates even it means more duplication. We could go even further I think but that's something else.

The problem is that this design brings not a lot of complexity in the templates but a lot of ifs. And I'm convinced now that the Underscore/Lodash template syntax is really not ideal.

In Yeoman, they mostly use Grunt. They choose to change the problem by creating a modeled version of the gruntfile:

• This means that using it remove the gruntfile template from the generator for something entirely defined programmatically, I wonder if it's good.
• As Grunt is configuration oriented, the model is quite simple to define, as Gulp is code oriented it's a lot more complicated.

So finally, I see several choices:

• Considering starting Gulp Editor library but it will create some limitations and there is the problem of loosing the templates.
• Find another existing template engine. I already looked quite deeper. There are all optimized for HTML generation. I didn't find one ideal for code generation.
• Create an optimized template engine for our specific use. We basically need almost only if statements with a good whitespace / line break control.
• Continue as it is :)

[srsgores]

@swiip, have you considered using something like gulp fiction to get the codebase started?

[Swiip]

I took a deep look a gulp fiction. It's implemented as a front end service, it's exactly an implementation of a kind of Gulp Editor library. It could be interesting.

To be precise its a little different of Grunt Editor as Grunt Editor directly use an AST view of the future gruntfile when gulp fiction construct an abstract representation before transforming it.

[Swiip]

I can't stop myself thinking on this today. The gulp fiction model can't handle our current build.jscomplexity. So, I've look at the grunt editor which leads me to the ast-query project which is behind. It's very interesting but once again, the complexity of a gulpfile can't be handled: chaining pipes are a mess at the AST level.

So, I digg on the specific template engine solution. I've come up with a literate inspired / markdown based syntax. What do you think of this?

https://gist.github.com/Swiip/49d500b424ffeb3ceff7

[Swiip]

Moving to a non standard template system scares me. I thought the real problem of the current template is that we want output files with no white lines so we have to put the templates controls at the end of the lines which is not readable.

So I've just made a test with a replace all which removes this white lines which ables us to put the controls on the beginning of the lines and its quite enough. It's looks like this:

function process(content) {
  return _.template(content.toString().replace(/\n<%/g, '<%'), data);
}
...
this.fs.copy(this.templatePath(key),  this.destinationPath(value), { process: process });

[srsgores]

So is this still in the plans for the future? I see you've closed this issue...

[Swiip]

I written in this thread all my thought on this subject. To sum up, gulpfile code is too complicated to be generated the same way the gruntfile-editor works. It could be feasible but my skills in AST manipulations are not enough.

So we keep templating. I just added a small feature to the template engine to be able to indent correctly and make them more readable.