.html extension can't be used for input even in safe cases about nunjucks-cli HOT 7 CLOSED

Sorry for the delay.
You guys are right, I will implement in the next days a simple boolean flag to allow use of .html.

For the record, I chose to forbid the use of .html as a source, simply because I overwrote a lot of my source files during the developement of this module, and it made me precautious about it.

from nunjucks-cli.

This feature seems like it could be desirable under a flag, but what is your use case for it, @thijsvandien? It would seem to me like the reason to care about the extension is that your text editor is not highlighting the code correctly and that is easily configurable in your editor. Can you elaborate a bit on why you want this?

from nunjucks-cli.

I'm also voting for support of this feature: allow templates to have *.html extension.
Templates are HTML files with some extended syntax so, why not to let any editor immediately recognize it as HTML via extension?

My use case it npm script:

"scripts": {
  "build-html": "nunjucks *.html -p src/html/ -o dist/",
  ...
}

There is no way that problem described in warning message can happen:

To avoid overwriting your templates, do not use html as file extension

from nunjucks-cli.

Also the example in Nunjucks official documentation uses html extension for templates:

{% extends "parent.html" %}

{% block left %}
This is the left side!
{% endblock %}

{% block right %}
This is the right side!
{% endblock %}

from nunjucks-cli.

Indeed, I am not a fan of custom extensions where there are acceptable standard ones. As @darklynx said, .html is semi-offical here. Source files being overwritten is an exceptional case, the guard for which has a disproportional impact on the happy path.

from nunjucks-cli.

I find the idea of @homosaur is really good: add a special cli flag to allow .html extension for templates. By default for inexperienced users the tool will refuse to accept templates under .html extension, however the more experienced users may enable this possibility and they were already warned by default behavior and warning message.

from nunjucks-cli.

Initially I was thinking of simply comparing the input folder to the output folder and not warning if they're distinct, since nothing can happen then. Having given it some more thought, I realize it may not be that easy when relative paths get involved. There is no such thing as the input folder and the output folder. Instead, the program would have to make a list of files that are going to be read and files that are going to be written, before actually doing so, and from that determine if there are going to be conflicts. As much as I'd like to keep the API minimal, the implementation simplicity of a flag has a strong edge here, unless there are other advantages to such preprocessing (caching?).

from nunjucks-cli.