[feature request] Allow the `views` options as an array of paths

[webdiscus]

Hallo @nebrelbug,

thanks for the new cool version 3.
But v3 has many breaking changes and fails some very important options or functions.

views option as an array

Many templating engines have the views option as an array of paths where will be searched partials.

Currently, the views option is as the '{ string }'

{
  views: path.join(__dirname, 'src/views/partials'),
}

Please, add the views option as the '{ Array< string > }'

{
  views: [
    'src/views/includes',
    'src/views/partials', // allow relative path
    path.join(__dirname, 'src/views/partials'), // allow absolute path
  ],
}

Also the views options should be { string | Array<string> }.

[nebrelbug]

@webdiscus having views be multiple directories is significantly slower, since you need to search each directory to see if the template exists.

Is there any concrete use case that's impossible using a single views directory?

[webdiscus]

@nebrelbug,

defaults, the view option can be as the string and searching is quicky, but for complex project structure lets to use "slow" but flexible option as the array.

I use the Eta as preprocessor in the html-bundler-webpack-plugin. This plugin is used by many projects that have complex branching directory structure. I will upgrade Eta from v2 to v3, but it will bring breaking changes and for my users.
I known, in v3 some enhancements like renaming includeFile into include are very great, but with otherside the new version requires many many manual adaptation of paths in templates. Nobody will do it.

For example:

src/views/includes - big includes like header, footer, banner, etc.
src/views/partials   - small partials with variables, like navi, menus, etc
src/views/layouts   - page layouts
src/views/pages     - main page skeleton
etc.

In a page template can be included files from different directories.
The views (or like) option as an array is standard de facto by all popular engines: Ejs, Handlebars, Nunjucks, Liquidjs, etc.

How will fast render can use the option as string for single path.
But flexibility and compatibility are much more important.

P.S. I appreciate your project and the improvements in the new version, but unfortunately the new version has been degraded in flexibility and compatibility.

[nebrelbug]

@webdiscus I understand where you are coming from, but I feel like this new structure is better for the project and for new users. I think users will be happy to write include("./layouts/main") instead of include("/main") if it decreases ambiguity and improves speed.

I'm open to continued feedback about this though.

[webdiscus]

@nebrelbug,

You are right, I'm personally for using truth path include("./layouts/main") instead of include("/main").
For a new project it is no problem.

The big problem is the compatibility with huge number already exists projects, whith already use the views options as an array with many directories.

Please, keep the compatibility for "legacy" but yet actual projects.