Merge site.copy and site.loadAssets?

[oscarotero]

This is an idea that would like to discuss and hear the opinion of more people. If it's approved, it's a huge breaking change so it would be implemented in Lume 3 (that I don't have plans to work on that anytime soon).

Currently, Lume has several ways to output files to the site:

• Pages: They are the files intended to generate HTML files. They use template engines and layouts to render. The output path is the filename but replacing the original extension with .html or /index.html (depending on the prettyUrls configuration). For example /dir/page.md generates /dir/page/index.html.
• Assets: Similar to Pages but they are not rendered, only (pre)processed. The output filename is the same as the source filename. For example /dir/file.css generates /dir/file.css.
• Static files: They are files that are not loaded in memory but copied when all pages and assets are saved to the dest folder. They are configured with site.copy().

The problem is assets and static files serves a similar purpose: output non-html files. But due static files are copies as is, they are not processed, so plugins like postcss, transform_images, sass, svgo, etc don't work with these files.

Let's see the following example:

site.copy([".css"]);
site.use(postcss());

In this configuration, the build copy all CSS files and you may expect these files to be transformed with the postcss plugin. However the plugin only works with assets. I think this behavior may be confusing.

Static files exist to avoid loading in memory files for no reason. Only files that must be transformed (compiled, minified, etc) should be loaded in memory. It's a copy of the Passthrought File Copy feature of Eleventy.

But I think Lume should be more clever than this, instead of delegating to the user the decision of configuring a file to be loaded or copied, depending on the selected plugins. My idea is to merge site.copy() and site.loadAssets(). This will remove duplicated code and simplify the internal implementation. This new feature could have the generical name of Files.

Files are not loaded initially (like static files) but will be on demand. If a file is being processed, the content will be loaded automatically. For example:

site.files([".css"]); // Copy files

site.files([".css"]); // Copy files

site.process([".css"], (files) => {
  // The content of the .css files is loaded before run this processor
});

How to rename files?

Due to files are not loaded initially, we cannot include data like a frontmatter with the url value to change the output path. We can use _data files to define a url function or change the basename of the folder.

We can also use preprocessors to assign data to the files without loading it (file content would be loaded only for processors, not preprocessors). For example:

site.preprocess([".css"], (files) => {
  files.forEach((file) => changeUrl(file);
});

Static files allow to rename of the file in the copy function. For example site.copy("assets", ""). We can implement the same feature on files.

Thoughts?

[hpfast]

Hi, I certainly think it would be good to simplify this! It took me a while to figure out why things weren't working when I was trying to get a js file loaded while exploring #580. using site.copy() seems to override an earlier site.loadAssets(). This is definitely confusing. If the API surface is reduced from two to one functions, there's less opportunity for unsuspected interactions.