Triggering update from beforeUpdate

I have some js that I bundle with esbuild. Writing a plugin for it, I ended up with something like:

const built = new Set();
site.loadAssets([".js"], async filename => {
  built.add(path.relative(site.src(), filename));
  // call esbuild on file
  return {content: esbuildOutput.content };
});

I make sure that all the dependencies are in an ignored dir, and everything works fine.

Now I want to update the main bundle when one of the deps change. I did something like:

site.addEventListener("beforeUpdate", async ev => {
  for (const filename of ev.files) {
    if (!filename.endsWith(".js")) continue;
    if (built.has(filename)) continue;

    await site.update(built);
    return;
  }
});

This “works”, except that this triggers the whole update cycle twice (including all afterUpdate events). If instead of doing this, I simply add the files to ev.files, it doesn’t work because the beforeUpdate of core/source doesn’t get called on the new files.

So now I’m stuck: there’s no way to restart or cancel the current update, and no way to ask source to clean the cache just for this file. What would be a good idea here?

[fserb]

Yeah. The Deno blunder is not even close to good enough for this (to be fair, it’s not designed for this). I need inline source map, minification (and keeping top names, because of WebComponents), tree-shaking, backward compatibility js version support, etc.

I’ll try Asset/process version, I think I tried it before and failed, but I’ll report back.

[oscarotero]

I love to hear good ideas for Lume, so don’t worry 😃

Your idea of the Format type sounds great, but I’m not sure if it covers all use cases. For example:

• A format has a loader assigned, a function responsive to read the file content. You can see the different loaders here.
• There are two types of files: pages and data. The same format can have different loaders depending on the type. For example:
  • .js files can be loaded as text files, because they aren’t executed, but bundled, minified, etc.
  • But javascript data files (like _data.js or _data/site.js) are loaded as javascript modules, because they need to be executed at the build time.
• Formats are used also to detect the template engine used to render the pages. For example:
  • The page about-me.njk uses the Nunjucks template engine.
  • A page with the variable layout: main.pug uses the Pug template engine to render the layout file in _includes.
  • A page with the variable templateEngine: njk,md will be rendered twice, first using Nunjucks and then markdown see this
• Processors and preprocessors use also the extensions to determine if a file must be processed before/after rendering. Both extensions (src and dest) are used. Let’s say we register a processor to minify .css files:
  • A sass file (.scss) that ouputs .css is processed, because the extension is present in the dest file.
  • A .css file is processed too because the extension is present in the src file.

File extensions can cover all these casuistry with a single api (just prefix the format at the end of the file name) and it works in both directions (you can register anything (loader, processor, etc) for all files of the same extension; and you can assign a extension to a individual file). In addition to that, you don’t need to see the code in the _config.js file to find out how a file will be loaded and processed, because it’s clear in the file extension that, for example, a .md file is a markdown file that will be loaded and render as markdown.

Your proposal could work as a low level API to handle this but I see some limitations, for example how to use my format (in your example) as a format for layouts stored in _includes? or for processors/preprocessors? The format priority to resolve conflicts sounds a bit hacky…

Anyway, I’ll keep thinking about this and open for suggestions.