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

    Interface ImportedEntity<K>

    a description of an entity that is imported by an output file (post-build, during the emission stage).

    • for user-specified imports performed in the transformation stage (OnTransformResult), the key will be supplied by the user, and it will be up to the user to trace back the original linked resource that was being referenced.
    • for imports performed by esbuild (such as js and css imports), the key will be an array of namespaced resolved paths (of the form ${namespace}:${resolved_path}) that contributed to the creation of the imported (and possibly bundled) resource.

    TODO: the currently include with import attribute is defunct. should it have any built-in purpose, or should it be just left up to the user to decide what to do with that information?

    interface ImportedEntity<K = any> {
        key: K;
        with?: Record<string, string>;
        outputPath: string;
        initialPath?: string;
        kind: any;
        external: boolean;
        write: boolean;
    }

    Type Parameters

    • K = any

    Hierarchy

    Index

    Properties

    key with? outputPath initialPath? kind external write

    Properties

    key: K

    include a unique key that you can use to trace back the imported entity, because the path of the import in the bundled output will differ, whereas this key will remain the same.

    with?: Record<string, string>

    associate a with import attribute to the import.

    outputPath: string

    the absolute output path of the resource/entity that is being imported.

    to convert it to a relative path with respect to the entity that imports this resource, use the relativePath function from my jsr:@oazmi/kitchensink/pathman or npm:@oazmi/kitchensink/pathman libraries.

    initialPath?: string

    if the imported entity was renamed during the , emission stage, then its original (absolute) outputPath will get saved here.

    this is to aid you with modifying/renaming import paths within your dependent entity's OnEmitArgs.contents, when you cannot reliably use your key to identify the import statement corresponding to an imported entity.

    for instance, suppose your build emits a ./main.js file that imports ./meow.worker.js, and then during the emission stage, suppose you renamed the ./meow.worker.js output file to ./workers/meow.js. then, when ./main.js enters the emission phase, the import field corresponding to the ./workers/meow.js file (formerly ./meow.worker.js) will have its outputPath set to ./workers/meow.js (but as an absolute path), while its initialPath will get assigned ./meow.worker.js (again, as an absolute path), so that you can scan the OnEmitArgs.contents of your ./main.js file to find all references to ./meow.worker.js, and then replace those statements with the updated ./workers/meow.js path.

    Note

    this field is only assigned when the emission stage result of the dependency import changes the OnEmitResult.path to something different from the original (case sensitive).

    kind: any

    indicates the kind of import that is being performed. all of these are inherited from esbuild metafile's EsbuildMetafileImportProps.kind | kind field, with the exception of "user-import", which is assigned when the user specifies an import during the transformation stage (OnTransformResult).

    external: boolean

    indicates if this imported entity is an external resource (and hence not bundled).

    write: boolean

    this flag indicates if the imported file entity is being written at all into the filesystem (supposing that the EsbuildBuildOptions.write was not disabled).

    in general, this flag is set to false for entities with external set to true. but for non-external imported entities, when this flag is set to false, it can hint to the importer entity that they should probably remove the import statement associated with this import, in order not to get any runtime-import exceptions. or perhaps, it can hint that the imported entity should have its contents inlined into the importer, such as in the case of html's inline js and css. (TODO: currently, importers cannot read the contents of the imported entity, so this feature needs to be implemented).

    Settings

    Member Visibility

    On This Page

    Properties