This function must, given a specified locator, find the location where it has been installed.
Note that contrary to fetchers (that are allowed to return relatively complex type of data source thanks to their filesystem abstractions), this function is only allowed to return a path. That being said, the way this path is interpreted is open to the package manager, though - in practice it will be used on a ZipOpenFS, so you can return paths from within zip archives.
Note that contrary to fetchers (that are allowed to return relatively complex type of data source thanks to their filesystem abstractions), this function is only allowed to return a path. That being said, the way this path is interpreted is open to the package manager, though - in practice it will be used on a ZipOpenFS, so you can return paths from within zip archives.
The queried package.
The link options.
This function must, given a specified location on the disk, find the locator for the package that owns it. This function is allowed to fail if the location doesn't seem to be owned by any package covered by the current linker, in which case it should return null.
The main case where this function is called is when a postinstall script for a third-party package calls another script of its. In this situation, we must figure out who's making the "run" call, and we can't really rely on anything else than the location on the disk to do so.
The main case where this function is called is when a postinstall script for a third-party package calls another script of its. In this situation, we must figure out who's making the "run" call, and we can't really rely on anything else than the location on the disk to do so.
The queried location on the disk.
The link options.
Return an arbitrary key.
This key will be used to save and restore the installer's custom data. You typically will want to return the installer's name, but you can be fancy and send a stringified JSON payload that include the cache version, etc.
This key will be used to save and restore the installer's custom data. You typically will want to return the installer's name, but you can be fancy and send a stringified JSON payload that include the cache version, etc.
This function must instantiate an Installer object that describes how to install the packages on the disk. Check the Installer file for more details on the installer design.
The link options.
This function must return true if the specified package is understood by this linker. Given that this function takes a package definition as parameter (not only a locator), it's safe to use the languageName field as detection method.
The link options.
Generated using TypeDoc
Linkers are the glue between the logical dependency tree and the way it's represented on the filesystem. Their main use is to take the package data and put them on the filesystem in a way that their target environment will understand (for example, in Node's case, it will be to generate a .pnp.cjs file).
Note that multiple linkers can coexist in the same dependency tree. This makes it possible to have a unique dependency tree containing packages from different linkers.
Note that multiple linkers can coexist in the same dependency tree. This makes it possible to have a unique dependency tree containing packages from different linkers.