Add support for directory-specific configuration files (`.ivfi` dotfiles)

[sixem]

This PR adds support for directory-specific configurations while also streamlining the previous .indexignore feature into this new feature.

Usage

If the script detects a dotfile (.ivfi file) in the current directory, it'll read and parse its values and apply it to the script. This makes it easy to hide certain files or extensions in a specific directory, set the metadata for a specific directory and so on.

Example

An example of an .ivfi file:

{
    "metadata": [
        { "property": "og:description", "content": "This is a custom description." },
        { "charset": "iso-8859-1" }
    ],
    "metadataBehavior": "overwrite",
    "ignore": ["*.md"],
    "exclude": ["png"]
}

metadataBehavior can be changed between overwrite or replace, which respectively either overwrites previous metadata values or replaces them all completely.

ignore accepts an array of strings which contains the files to hide. This works in the same way as the previous .indexignore.

This feature will still have to be tested a bit, and more options can be added to it.

[sixem]

Thank you for your feedback.

Tested and works excellently.

I was wondering what you think about a hierarchy system. If a .ivfi file is in a folder, the edited settings also apply to all sub-folders unless specifically overwritten by another .ivfi file that specific sub folder. What do you think about this idea and would it be possible or too time consuming/not compatible with the index system.

That would've been good, but I doubt it's possible to do in a good way. We're only dealing with the contents of the current directory each requests, so knowing what's deeper down in the structure won't be available unless we also scan that each request. I suppose it could've been possible to just map out the entire structure on server start, keeping a cache of all the configuration files, but that still wouldn't solve the issue of when we update them or create new ones while the server is running. I don't think it's really feasible at the moment, unfortunately, unless I'm overlooking something.

However, there is a different way of achieving something similar with the processor option:

server.run(port, directory, {
    processor: (data: any) =>
    {
        const hasDotFile = data.contents.files.find((file: any) => file.name === '.ivfi')
            ? true
            : false;

        if(!hasDotFile && data.req.startsWith('/Images'))
        {
            data.metadata = [
                { charset: 'utf-8' },
                { name: 'viewport', content: 'width=device-width, initial-scale=1' },
                { name: 'description', content: 'Some description.' }
            ];

            data.contents.files = data.contents.files.map((file: any) =>
            {
                if((file.name).split('.').pop().toLowerCase() === 'jpg')
                {
                    file.hidden = true;
                }

                return file;
            });
        }

        return data;
    }
});

This is more of a hands-on approach that applies metadata and hides files specifically for /Images/ and its sub-directories if a dotfile isn't present. It may serve a similar purpose.

[evwltrs]

Using the processor sounds like an interesting idea, I'll do some more testing with that. This feature works great and should be ready for merge 👍.

[sixem]

I also added the dotfile presence to the object that is being passed to the template and the processor option, as that can't possibly hurt.

I'll go ahead and get this merged now. Thank you for the feature suggestion! I think this is a cool little feature to have, as it adds an easy way of tinkering a bit with specific directories.