Templates and preprocessors coupling

[UltCombo]

Currently, harmonic init/config asks for both a template and a preprocessor. However, as previously discussed, each template will only be written with a single preprocessor.

In this case, it does not make much sense to have independent template and preprocessor choices at the moment. That is, what happens if the user chooses the default template (which is written in Stylus) and chooses Sass as the preprocessor?

How can we best solve this issue?

My initial idea would be to couple templates and preprocessors into a single choice, e.g.:

Template and preprocessor:
- default (Stylus)
- harmonic-template-x (Sass)

Is there a better solution?

[jaydson]

I think we'll need a template manifest.
So, the default template manifest will need Stylus, and so on for other templates.
Something like this:

{
  "name" : "default",
  "preprocessor": "stylus"
}

To achieve this, we need to define the whole process of creating templates.

[atilafassina]

+1 on the manifesto idea for the templates

But also, I think Harmonic should come with a Boilerplate template, and then it would make sense to ask what preprocessor the user would like.

For example:

If the user chooses the default template, Harmonic follows on and doesn't ask for a preprocessor.

But, if the user chooses the Boilerplate (or whatever name, I was think this would be our "blank" template), then Harmonic asks what is the preprocessor of choice among those supported.

If the user chooses Stylus, for example, at src/styles Harmonic puts a main.styl. Since all major preprocessors support single-line comments, only the extension will need to change... the contents of the files can be simple instructions of how to start, or even advise on how to organize the directory tree, mixins, etc...

[UltCombo]

Not sure if we actually need a template manifest.

Templates already can have their own config.json which extends the main config. It is currently possible for a template to set { "preprocessor": "x" } in its config.json.

Also, I'm not sure if we need a template name field. Although a custom name could provide some more freedom to template authors, I believe it'd be less confusing for the end user to just see the same names which s/he has typed on npm install, to make clear the relation between what is installed and what the user is choosing.

I'm not opposing a template manifest, it would surely be useful for extensibility. I'm just mentioning it is not quite necessary for our current use cases.

[jaydson]

Well pointed @UltCombo .
The template manifest must be the current config.json, it makes sense.