Feature Request: Build metadata as first-class, typed property of build result

[ggoodman]

When my use-case requires looking at the build metadata, it feels like some non-value-added work is required to extract this from emitted files. When using esbuild programmatically, this is especially true. I would love if the build metadata could become part of the explicit build result API. It would make using esbuild safer since consumers wouldn't need to build their own, potentially divergent types for the extracted metadata.

[evanw]

Well put. I already have my eye on this change, but it would be a breaking change so I'm waiting until the 0.9.0 release.

It would make using esbuild safer since consumers wouldn't need to build their own, potentially divergent types for the extracted metadata.

The metadata types are already published:

esbuild/lib/types.ts

Lines 214 to 238 in 36efd93

	// This is the type information for the "metafile" JSON format
	export interface Metadata {
	inputs: {
	[path: string]: {
	bytes: number
	imports: {
	path: string
	}[]
	}
	}
	outputs: {
	[path: string]: {
	bytes: number
	inputs: {
	[path: string]: {
	bytesInOutput: number
	}
	}
	imports: {
	path: string
	}[]
	exports: string[]
	}
	}
	}

No need to build your own potentially divergent types.

[ggoodman]

Great news to hear that this is on your radar @evanw. I wonder if you have any ideas about what sort of metadata you're thinking about including. I understand that this is basically an append-only contract (because semver) 😅 so you might be reluctant to add everything and the kitchen sink in there.

From my perspective there is likely some metadata that is already available in-memory that would be interesting for consumers. I'd love to see the following be available (not sure whether at the input file or output file granularity) for build and even for transform:

1. Imports: I'd like to see the imported module specifier, the symbols imported and their local bindings.
2. Exports: I'd like to see the exported symbol names.

I'd love to hear what you have in mind!

[ggoodman]

Hi @evanw, I've kept on playing with esbuild and have noticed that while the types are defined as you've linked, they are actually partially inaccurate. I suspect that go's default value semantics are resulting in some fields being omitted from the generated json.

For example, all fields of the outputs[*] objects are marked as defined. In practice, these are sometimes omitted (specifically, .imports for output entries).