@oazmi/esbuild-plugin-deno - v0.4.0
    Preparing search index...

    Interface CommonPluginData

    this is the common plugin data utilized by the resolvers in resolverPlugin esbuild-plugin.

    interface CommonPluginData {
        importMap?: ImportMap;
        runtimePackage?: RuntimePackage<any>;
        resolverConfig?: {
            useInheritPluginData?: boolean;
            useImportMap?: boolean;
            useRuntimePackage?: boolean;
            useNodeModules?: boolean;
            useRelativePath?: boolean;
        };
        [capture_marker: symbol]: boolean;
    }

    Indexable

    • [capture_marker: symbol]: boolean
    Index

    Properties

    importMap? runtimePackage? resolverConfig?

    Properties

    importMap?: ImportMap

    specifies the current scope's import-map aliases. the keys of this object hold the aliased name of the import, while the values hold the absolute path of the referenced resource.

    for further reading on import maps, see ImportMap.

    runtimePackage?: RuntimePackage<any>

    specifies the current scope's runtime package manager (such as deno, jsr, npm, node, etc...), so that the package's own import and export aliases can be resolved appropriately.

    resolverConfig?: {
        useInheritPluginData?: boolean;
        useImportMap?: boolean;
        useRuntimePackage?: boolean;
        useNodeModules?: boolean;
        useRelativePath?: boolean;
    }

    you may control which resolvers to disable through the use of this property.

    Type declaration

    • OptionaluseInheritPluginData?: boolean

      enable or disable missing pluginData inheritance (performed by the entryPlugin) for the current entity.

      setting this to false will make the inheritance injector not record this entity's pluginData. thus, in effect, all of the current entity's dependencies will not be able to inherit this entity's pluginData, even when they (the dependencies) are lacking one (i.e. dependency_args.pluginData === undefined).

      this could be useful when switching the scope to a new, isolated, package. but you could also strip away the plugin data in the current entity so that its dependencies don't pick up anything. so, the only scenario where this could be useful is when:

      • you've got a custom loader, which requires some pluginData specific to the current entity.
      • but your loader also returns puginData: undefined, making its dependencies acquire dependency_args.puginData === undefined.
      • however, you don't want dependency_args.puginData to now inherit from args.pluginData (the importer's plugin data).
      • thus, to solve this issue, you make sure that the importer's args.pluginData is never recorded by the inheritance resolver. so, you achieve that by setting args.pluginData.resolverConfig.useInheritPluginData to false.

      true (enabled)

    • OptionaluseImportMap?: boolean

      enable or disable import-map resolution for the current entity.

      true (enabled)

    • OptionaluseRuntimePackage?: boolean

      enable or disable runtime-package resolution (such as "deno.json") for the current entity.

      true (enabled)

    • OptionaluseNodeModules?: boolean

      enable or disable node_modules file resolution for the current entity.

      true (enabled)

    • OptionaluseRelativePath?: boolean

      enable or disable relative-path to absolute-path resolution for the current entity.

      true (enabled)

    Settings

    Member Visibility

    On This Page

    Properties