@oazmi/superbuild - v0.3.2
    Preparing search index...

    Interface OnEmitResult

    type alias for esbuild.OnEndResult.

    interface OnEmitResult {
        path?: string;
        contents?: string | Uint8Array<ArrayBuffer>;
        write?: boolean;
        reEmit?: boolean;
        reEmitData?: Record<PropertyKey, any>;
    }

    Hierarchy (View Summary)

    Index

    Properties

    path?: string

    provide an alternate path to place this resource.

    if a relative path is provided (which is what is recommended), then this file will be placed relative to the cwd or absWorkingDir specified in the initial build options, which is different from the outdir. for providing paths relative to outdir, use an absolute path.

    TODO: in the future, consider adding a pathRelativeTo option, with the symbols OUTDIR, CWD, and ABS_WORKING_DIR, for specifying what is the path relative to.

    contents?: string | Uint8Array<ArrayBuffer>

    the contents of the file after you've re-incorporated the imported/dependency links into it. if left undefined, then the original OnEmitArgs.contents will be used as its value.

    write?: boolean

    specify if the file should be written (i.e. emitted) at all.

    Note

    note that it is totally possible to delete an entity, but still have some contents assigned to it. this way, you should be able to read the contents of the "deleted" file later on inside on of the dependent entities.

    this can be useful when you would like to code a plugin that takes in inlined code (such as inlined js or css inside an html), then includes it in the bundle (by faking it as virtual files during resolutions/loading), and then deletes the emitted files corresponding to the inlined code blocks, while retaining the minified/bundled contents, so that the original dependent entity (html file in this case) can read the minified/bundled contents and then re-incorporate them as inlined code.

    (TODO: though, right now, I don't currently give a global readonly access to the output files registry inside the OnEmitCallback function. I should probably add the registry as a second argument to the callback function.)

    true (i.e. it'll be written if EsbuildBuildOption.write is enabled, otherwise it won't be.)

    reEmit?: boolean

    declare if this resource is supposed to be re-emitted and passed through all registered onEmit handlers again from the beginning. this effectively lets you process a single emitted output entity through multiple onEmit handlers.

    Note

    in order to stop the current handler from intercepting and processing your re-emitted entity again, you should insert some kind of identifiable mark/symbol into the returned reEmitData field.

    it is similar to how I often insert a known unique symbol into build.resolve's pluginData, in order to identify if I've already encountered and processed a resource, so that I can skip it and let other onResolve hooks to handle it.

    false.

    reEmitData?: Record<PropertyKey, any>

    If you are re-emitting an output entity (so that it gets processed by other registered onEmit hooks after being mutated), then the next onEmit interceptor of this entity will receive this arbitrary record/dictionary in its OnEmitArgs.reEmitData field.

    this provides an effective means for inter-on-emit hook communication, akin to pluginData used in onResolve and onLoad. it also provides a way for you to stop the current output entity from being processed by your current onEmit hook again, by inserting a unique symbol into the reEmitData record, which, if discovered, will indicated that a given resource has already gone through the current handler.

    when this field is set to undefined, it will adopt/inherit its prior reEmitData declared under OnEmitArgs.reEmitData. in order to clear out this field properly, one must assign a new empty object to it.

    undefined, which in turn signals that it should inherit/propagate its prior reEmitData (i.e. OnEmitArgs.reEmitData).