@oazmi/superbuild - v0.1.0
    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.

    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.

    steps: LongBuildStep[] = []

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

    Methods

    • Parameters

      • Optionalpathname: string

      Returns void

    • Parameters

      • Optionalpathname: string

      Returns void

    • Parameters

      • args: OnResolveResult

      Returns void

    • 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, ImportEntity<any>[]>>