Outputting extensionless file (like _headers) from template

[valtlai]

I would like to dynamically generate a _headers file to configure HTTP headers for Netlify. (And I’m going to do something similar with _redirects too.)

There’s no way to output a file named _headers from a template (i.e. without using site.copy()). Setting slugifyUrls: false in the config file and url: /_headers in a front matter results a file _headers/index.html (or _headers.html if prettyUrls: false).

The problem is that the _headers file has no file extension and Lume adds .html for missing one.

Should we stop adding the extension and only add index.html if url has a trailing slash? Then url: /foo would output /foo and url: /foo/ would output /foo/index.html. Or should there be an option (such as forceExtensions: false) for this behavior?

[oscarotero]

I see some problems requiring trailing slash. For example if prettyUrls: false, you have to include the .html extension to all urls defined in the frontmatter.

One solution could be allow to set an object with properties for the url value. For example:

---
url:
  filename: _headers
  extension: false
---

The urlPage function could use these properties to define the final name, instead the default behavior. I imagine available possible properties: directory, filename and extension. Not defined values (directory in the example above), will use the default value.

What do you think?

[valtlai]

I like it. Should filename be path, because its value could include directories? What would directories do? Also, could there be pretty and slugify for overriding prettyUrls and slugifyUrls for a particular template?

[oscarotero]

directory would be the directory where the file will be saved. For example, the output file /posts/hellow-world/index.html would be:

url:
  directory: /posts/hello-word/
  filename: index
  extension: .html

If the directory is not defined, the src directory of the file will be used.

But I like more your idea of using path and extension, because it's the same values that we have in src and dest of every page, so it's more consistent:

url:
  path: /post/hello-word/index
  extension: .html

The difference between using this object and a string like url: /post/hello-word, is that with the object we are defining the final output filename (the value of dest) so I wouldn't apply the pretty and slugify transformations.

[valtlai]

That makes sense and I think this looks pretty good now.

Should the value used to omit the extension be null or an empty string instead, because the variable isn’t a boolean?

So the solution for this specific use case would be the following:

url:
  path: /_headers
  extension: null

[oscarotero]

Should the value used to omit the extension be null or an empty string instead, because the variable isn’t a boolean?

Yes, a null or empty string is better. Or maybe nothing:

url:
  path: /_headers

In this case, the extension would be empty.

[oscarotero]

@valtlai I just implemented this new feature. You can see an example here and the expected output here.

[valtlai]

That’s nice. However, relative paths aren’t supported with an object. Should them?

[oscarotero]

Good point. I don't see why not. I'll add it.

[valtlai]

One more question: How should a path with a trailing slash work?

url:
  path: /foo/

This currently throws an error. Is it ok or should it output /foo/index.html instead?

[oscarotero]

I think it's ok the error. This is the explicit way to define the output file, so I wouldn't change the value introduced by the user.

[valtlai]

That’s fine. I think this is ready, so closing.

[valtlai]

The commit 772f9e0 also changed how the following works:

---
url: /404.html
---

Before the commit, /404.html was outputted. After it, /404/index.html is outputted. Was that an intended change?

[oscarotero]

No, it's not intended. Let me see.

[valtlai]

This didn’t work even before the commit, but I think an input file 404.html.md should output 404.html and not 404/index.html as it currently does.

[oscarotero]

I think it's fixed now. And subextensions like 404.html.md are supported too (in fact this was implemented some time ago, but stopped working at some point).

[valtlai]

Thank you! It seems working now, so closing. :)