Use esbuild metafile. Add support for 'entryNames' esbuild option.

[into-the-v0id]

Description

Currently (before this PR) the esbuild plugin would always output JS asset files as options.outdir + replaceExtension(page.data.url). Which means The esbuild option entryNames would not work.

Additionally the esbuild plugin tries to map output files from esbuild to lume pages (JS eintry points). This looks similar to this:

const page = pages.find((page) => withoutExtension(page.sourcePath) === withoutExtension(outfile.path));

When entryPoints is set/changed this no longer works. The plugin then can not find a page for the outfile and adds it as a chunk.

When using the entryNames option like this:

site.use(esbuild({
  options: {
    entryNames: "js/[name].[hash]",
  },
}));

Given a source file scripts/index.ts you would get something like the following output files:

• js/index.WSRTVQIK.js
  • No src connection
  • Bundled and transformed file
• scripts/index.ts
  • Src connection: scripts/index.ts
  • No transforms - raw source file

This PR adds support for the entryPoints option. It now uses the esbuild metafile which contains information about input and output files and their relation. Using this metafile we can properly map esbuild outfiles to lume pages. It now also uses the esbuild outfile filename as final data.url:

page.data.url = outfile.path.replaceAll(
  dirname(page.sourcePath),
  dirname(page.data.url),
)

The replace is there to support url overwrites via basename. Using lume url overwrites in combination with the entryNames esbuild option works generally. However as we only write the file to a different location to what esbuild intended, JS imports to this file (e.g. via dynamic imports) are not rewritten! Esbuild currently does not offer any functionality to dynamically rewrite an outfile path per file (as far as I know). So this is as much as we can do.

I have also mostly reverted the changes from commit 13796a7 as that workaround is no longer necessary.

Related Issues

None

Check List

• Have you read the
  CODE OF CONDUCT
• Have you read the document
  CONTRIBUTING
  • One pull request per feature. If you want to do more than one thing,
    send multiple pull request.
  • Write tests.
  • Run deno fmt to fix the code format before commit.
  • Document any change in the CHANGELOG.md.

[oscarotero]

Thanks for this! I didn't know the metafile option but it seems very useful!
I just left some comments in the review, some of them are optional. To me, the most sensible part is the change of the output directory, which can break the code.

[into-the-v0id]

To me, the most sensible part is the change of the output directory, which can break the code.

Note that the previous implementation completely ignored the esbuild output path and just wrote it to page.data.url - which also breaks dynamic imports if we use lume url overwrites via basename.

[oscarotero]

Note that the previous implementation completely ignored the esbuild output path and just wrote it to page.data.url - which also breaks dynamic imports if we use lume url overwrites via basename.

Yeah, to be honest, I hadn't thought about that situation until now! :)
Thanks for your contribution. The esbuild plugin is much stronger now!