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

    Interface EntryPluginSetupConfig

    configuration options for the entryPluginSetup esbuild-setup factory function.

    interface EntryPluginSetupConfig {
        filters: RegExp[];
        initialPluginData?: Partial<InitialPluginData>;
        forceInitialPluginData: boolean | "merge" | "overwrite";
        enableInheritPluginData: boolean;
        acceptNamespaces: (undefined | string)[];
    }
    Index

    Properties

    filters: RegExp[]

    specify the regex filters to use for your initial-data-injection and path-resolver plugin.

    [RegExp(".*"),] (captures all input entities)

    initialPluginData?: Partial<InitialPluginData>

    this is a slightly modified version of CommonPluginData, which accepts a path or url to your "deno.json" file under the runtimePackage property.

    forceInitialPluginData: boolean | "merge" | "overwrite"

    specify the mode for forcefully inserting initialPluginData into args.pluginData of all entry-points:

    • false: don't insert initialPluginData into entry-points with existing args.pluginData.
    • true: equivalent to the "overwrite" option.
    • "overwrite": discard any existing args.pluginData, and replace it with initialPluginData.
    • "merge": join the old plugin-data and the initial plugin-data in the following way: { ...initialPluginData, ...args.pluginData }.

    false

    enableInheritPluginData: boolean

    specify if pluginData should be passed down from an resource to its dependency-resources, if they have been stripped off of their plugin data (i.e. dependency_args.pluginData === undefined).

    Note

    you might be questioning why would the dependency-resource lose the plugin data that its importer had?

    the reason is that esbuild's native resolvers and loaders strip away plugin data when any resource goes through them. (i.e. esbuild does not propagate the plugin data on its own if it resolves or loads something) moreover, poorly written plugins may do the same. which is why this option helps you retrieve lost plugin data from the parent dependent resource (the args.importer).

    Important

    generally, you would always want this to be left as true. otherwise, npm-packages and local-files, that are implicitly resolved by esbuild in this library, will lose their access to the import-maps and deno-package-resolver.

    true

    acceptNamespaces: (undefined | string)[]

    specify which namespaces should be intercepted by the entry-point plugin. all other namespaces will not be processed by this plugin.

    if you want your plugin to receive pre-resolved absolute paths under some namespace, instead of having to resolve the path yourself by joining paths and inspecting pluginData, then simply include it in this configuration property.

    [undefined, "", "file"] (also PLUGIN_NAMESPACE.LOADER_HTTP gets added later on)