Eliminate read overhead for in-source layouts
What happens when the directory option is set inside the metalsmith.source(), eg.
metalsmith
.source('src')
.use(layouts({
directory: 'src/layouts'
}))
// currently requires @metalsmith/remove?
.use(remove('layouts'))
There is a limited set of cases where removing the layouts may not be desirable (eg. a design system that needs to show the source templates)
Resolution of this issue:
- Add a test case
- Add an option that defaults to current behavior for non-semver breaking release
3 use cases:
- storing layouts in src dir purely by preference but not to be used differently than by this plugin (currently causes file read overhead, but may be solved)
- storing layouts in src dir to be included in the build (eg using front-matter on them, adding metadata to them with plugins, design system docs, static/cdn server)
- storing layouts in src dir to be used somehow but discarded from the build after (eg embedded in other files)
1 may be solved with .ignore:
metalsmith
.source('src')
.ignore(['layouts'])
.use(layouts({
directory: 'src/layouts'
}))
2 is the current default
3 can be solved with @metalsmith/remove
metalsmith
.source('src')
.use(layouts({
directory: 'src/layouts'
}))
.use(remove('layouts'))
The plugin can be adapted to use a different jstransformer method depending on input location (renderFileAsync for files outside metalsmith.source() and renderString for files inside). This eliminates the file read overhead of 1. and the and makes cautioning against putting them in metalsmith.source() irrelevant as a bonus.
Considering 2 should stay default, I'd say this is not worth implementing as it adds the responsibility of file removal to this plugin, and it should not make assumptions about these files. Repurposing issue to analyse options for using in-source layouts