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

    this an instance of this class can imitate deno import and export aliases resolution, including any connected workspace packages. check the base class WorkspacePackage for more details.

    Hierarchy (View Summary)

    Index

    Constructors

    Properties

    packagePath: string

    the path or url of the package json(c) file.

    the base class does nothing with this information; it is just there so that subclasses can make uses of this information (usually for resolving relative paths).

    packageInfo: DenoJsonSchema

    the fetched/parsed package metadata file's raw contents.

    workspaceChildren: WorkspacePackage<any>[]

    specify all child workspaces of this package.

    • the exports of every child-workspace package are inherited by this runtime package.

      example: if packageB is child-workspace of packageA, then packageA.exports would be a superset of packageB.exports.

    • similarly, the imports of this runtime package will be implicitly available for all child-workspace packages.

      example: if packageB is child-workspace of packageA, then packageA.imports would be a subset of packageB.imports.

      Note

      since child-workspaces are also considered to be dependencies of the parent package (the monorepo), each child-workspace would be available to for importation by all child-workspaces. in other words, sibling packages of the workspace would be able to import one another.

    Important

    the constructor of the subclasses do not typically parse the workspace paths from the provided schema, nor do they load the WorkspacePackage associated with those workspaces, since it would require asynchronous operations (such as fetch) which cannot be performed inside the constructor. this is why you would either need to manually add/push your child/parent-workspace WorkspacePackage object, or use the asynchronous fromUrl static method in the subclasses to take care of auto-loading and auto-injecting parent and child workspaces.

    workspaceParents: WorkspacePackage<any>[]

    specify all parent workspaces of this package.

    • the imports of this runtime package will be implicitly available for all child-workspace packages.

      example: if packageB is child-workspace of packageA, then packageA.imports would be a subset of packageB.imports.

    • the exports of every child-workspace package are inherited by this runtime package.

      example: if packageB is child-workspace of packageA, then packageA.exports would be a superset of packageB.exports.

    Important

    the constructor of the subclasses do not typically parse the workspace paths from the provided schema, nor do they load the WorkspacePackage associated with those workspaces, since it would require asynchronous operations (such as fetch) which cannot be performed inside the constructor. this is why you would either need to manually add/push your child/parent-workspace WorkspacePackage object, or use the asynchronous fromUrl static method in the subclasses to take care of auto-loading and auto-injecting parent and child workspaces.

    importMapSortedEntries: ImportMapSortedEntries

    the import-map entries of the package, sorted from the largest key-alias to the shortest.

    Note

    each subclass will have to assign on their own, in addition to ensuring the required sorting order.

    exportMapSortedEntries: ImportMapSortedEntries

    the export-map entries of the package, sorted from the largest key-alias to the shortest.

    Note

    each subclass will have to assign on their own, in addition to ensuring the required sorting order.

    Methods

    • get the path/url to the package's json(c) file.

      the base class does nothing with this information; it is just there so that subclasses can make uses of this information (usually for resolving relative paths).

      Returns string

    • create an instance of this class by loading a package's json(c) file from a url or local file-system path.

      Important

      the resulting new instance is cached (memorized), so that it can be reused if another query with the same normalized path is provided.

      why are we forcing a cache mechanism on the base class?

      because the workspace children/parents, in the WorkspacePackage subclass, are referenced by their absolute path, and resolving an import through a workspace package would involve the creation of that child/parent runtime package via this method, thus leading to an exponential number of redundant re-creation of identical package manager objects.

      Tip

      the constructor uses a "JSONC" parser (from @oazmi/kitchensink/stringman) for the fetched files. therefore, you may provide links to ".jsonc" files, instead of parsing them yourself before calling the super constructor.

      Type Parameters

      Parameters

      • jsr_package: string | URL

      Returns Promise<INSTANCE>