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

    Class LongBuildController

    the controller used for commanding the state of the "long build" plugin.

    Index

    Constructors

    Properties

    uuid: string

    the unique base filename that will be used by the longBuildPluginSetup plugin to insert its "long build" js file as an entry-point. the full filename format it will use will be: ${recursion_number}.(${uuid}).js.

    baseFilename: string

    the unique filename(s) that will be used for the "long build" js files. it is a computed value that evaluates to .(${uuid}).js, and the actual filename that gets inserted/injected will also have a leading number, signifying the "build/recursion number".

    for instance, the entry-point long build js file will be named: 0.(${uuid}).js, while the next recursive "long build" import within the 0.(${uuid}).js file will be named 1.(${uuid}).js, and so on (until a "long build" js file with zero external imports/includes is discovered, at which point we shall halt).

    depsFilename: string

    the name of the "long build dependency" file, as defined in LONGBUILD.DEPS_FILE.

    its value evaluates to deps.(${uuid}).js, and it is imported by each "long build step" js file as a dependency, in order to have a shared resource variable where all imports will get registered.

    resourceExtensionName: string = ".res"

    the custom extension name used by the dynamically imported resources in the "long build step" files. the paths to all resource imports in the long build step's prepared js file will be named ${resource_id as number}.res.

    pluginNamespace: string

    the namespace used by the longBuildPlugin. it is a computed value that evaluates to oazmi-superbuild-long_build-plugin-${uuid}.

    buildNumber: number

    the current build/recursion number. it starts with zero, and it is used for indicating the filename of the current "long build" file.

    remainingFilesCounter: number

    the number of files in the esbuild build process that are currently in circulation.

    • everytime a new file hits the "long build" plugin's onResolve hook, this value gets incremented by one, since a "new file is currently in circulation".
    • whenever a file gets successfully loaded via some plugin's onLoad hook, the SuperPluginBuild.onLoad overload decrements this shared-state counter, since a "file that was in circulation has exited".
    • a caveat to look out for is the fact that if any plugin calls SuperPluginBuild.resolve, this counter will get incremented again (double count), since the resolve request will go through our "long build" plugin's onResolve hook once again. to combat this double count, the SuperPluginBuild.resolve function decrements this counter whenever it gets called.
    encounteredPaths: Set<string> = ...

    esbuild caches the loaded result of an onLoad hook, based on the result of the onResolve hook's result.path and result.namespace (I don't know if esbuild also caches with respect to the with import attribute). but we don't want to count any cached paths towards remainingFilesCounter, since they won't be loaded again; which is why we need this hash-set to keep track of what has already been seen once.

    resourceIdCounter: ResourceId = 0
    resourceEntities: Map<ResourceId, WellDefinedImportEntity> = ...

    contains the list of all resources referenced by various LongBuildSteps, using the resource id as the key.

    steps: LongBuildStep[] = []

    a logging function for internal debugging. it gets called only when DEBUG.LOG is enabled.

    format: any

    specify what build format is being used by your esbuild's build process. this is important to specify correctly, as we will need to manipulate the input and output contents of the long-build file(s) for the following reasons:

    • iife does not support top-level awaits, hence this mode requires us to wrap the logic inside an async function. furthermore, iife results in no variable exports; hence the bundled output will need to be changed so that it exports the resourceImports variable as an es6 module.
    • cjs does permit top-level awaits, but does not permit es6 exports. hence the need for additional manipulation of the output.
    • esm faces none of these issues, and it is the base format which we maipulate for the other scenarios.

    Methods

    • Parameters

      • Optionalpathname: string

      Returns void

    • Parameters

      • Optionalpathname: string

      Returns void

    • Parameters

      • args: OnResolveResult

      Returns void

    • declare a new resource that is to be appended to the list of all resources referenced by the long build file(s). the returned value is a new resource id for the added resource, which can be used as a key for retrieving back the added resource, using the resourceEntities Map.

      Parameters

      • resource_props: WellDefinedImportEntity

      Returns ResourceId

    • this function does the inverse of prepareLongBuildFileContent; it parses the js-transpiled contents of the "long build" file and extracts/reconstructs the resource import Map from it.

      since I plan on using a dynamic script import() to execute the contents of a modified version of the "long build" file content, this method has to be made asynchronous. I'm certainly not going to be using eval or the Function constructor, because they are often restricted in some js-environments.

      Parameters

      • longbuild_file_contents: string

      Returns Promise<Map<string, WellDefinedImportedEntity[]>>