Metafile input and outputs relative to the current working directory

[matthewmueller]

I recently discovered the Metafile option which is very handy!

Problem

One issue I've run into is that the metafile's input and output paths are relative to the current working directory. In a build script, the current working directory can change. Sometimes, you're building from one directory, sometimes you're calling the script from another directory.

This makes it hard to consistently pinpoint the original files.

Here's an example:

{
  "inputs": {
    "../duo-blank/node_modules/svelte/internal/index.mjs": {
      "bytes": 51679,
      "imports": []
    },
    "../duo-blank/views/components/form.svelte": {
      "bytes": 3536,
      "imports": [
        {
          "path": "../duo-blank/node_modules/svelte/internal/index.mjs"
        }
      ]
    }
}

In this case I was building from another project.

Suggested Solution

Make the metafile's input and output paths relative to something that can be explicitly set. I'd probably say the Outdir.

[lukeed]

+1 on this! But all paths should be absolute IMO because all other paths emitted by esbuild are already absolute (result.outFiles[] for example). Allows you to skip the guesswork of resolving an absolute path & still be confident when reconstructing paths relative to input/output paths.

[evanw]

Make the metafile's input and output paths relative to something that can be explicitly set. I'd probably say the Outdir.

It should probably be relative to outbase instead of outdir. I think that'll lead to cleaner paths and will be more relevant, since you might run the same build multiple times with a different outdir but the same outbase.

+1 on this! But all paths should be absolute IMO because all other paths emitted by esbuild are already absolute (result.outFiles[] for example). Allows you to skip the guesswork of resolving an absolute path & still be confident when reconstructing paths relative to input/output paths.

That's a fair point. These were my reasons for keeping relative paths:

• Currently the contents of all output files are consistent (byte-wise identical) across all platforms and they don't change when you move the directory around. This seems like a useful property to uphold because it means builds are easily reproducible (e.g. they will always hash to the same thing).

• The absolute path could be considered sensitive/private information because it contains the project name and/or the home directory. This could matter if the metafile is uploaded to third-party services for analysis.

• Currently the paths are relative and they always use / slashes, so they are platform-independent. Using absolute paths means people may try to manipulate the paths with code that works on normal systems but breaks on Windows because it's not aware of Windows-specific path conventions (e.g. \ slashes, drive letters, UNC paths, etc.).

I'll think about changing this since I agree that using absolute paths seems cleaner (less to configure or think about). Another change I've been thinking of making is having the API return the metafile JSON directly as an in-memory object instead of as an output file, since it'd make the API easier to use. In that case it's no longer an on-disk file, so some of these points would be less relevant. And it's not obvious that you'd have to set something like outbase to change the root directory for the metafile.

[aleclarson]

It would be nice to have this fixed :)

[dbushell]

Thank you for the explanation!

I was confused why the WASM version had different paths (I'm using Deno). They are effectively absolute without a leading / whereas non-WASM get relative paths.

I would prefer absolute but either way ideally metafile paths would be identical in WASM vs non-WASM.