| 1 | import { PortablePath } from '@yarnpkg/fslib';
|
| 2 | import { Installer } from './Installer';
|
| 3 | import { Project } from './Project';
|
| 4 | import { Report } from './Report';
|
| 5 | import { Locator, Package } from './types';
|
| 6 | export declare type MinimalLinkOptions = {
|
| 7 | project: Project;
|
| 8 | };
|
| 9 | export declare type LinkOptions = MinimalLinkOptions & {
|
| 10 | report: Report;
|
| 11 | };
|
| 12 | /**
|
| 13 | * Linkers are the glue between the logical dependency tree and the way it's
|
| 14 | * represented on the filesystem. Their main use is to take the package data
|
| 15 | * and put them on the filesystem in a way that their target environment will
|
| 16 | * understand (for example, in Node's case, it will be to generate a .pnp.js
|
| 17 | * file).
|
| 18 | *
|
| 19 | * Note that *multiple linkers can coexist in the same dependency tree*. This
|
| 20 | * makes it possible to have a unique dependency tree containing packages from
|
| 21 | * different linkers.
|
| 22 | */
|
| 23 | export interface Linker {
|
| 24 | /**
|
| 25 | * This function must return true if the specified package is understood by
|
| 26 | * this linker. Given that this function takes a package definition as
|
| 27 | * parameter (not only a locator), it's safe to use the languageName field
|
| 28 | * as detection method.
|
| 29 | *
|
| 30 | * @param locator The locator that needs to be validated.
|
| 31 | * @param opts The link options.
|
| 32 | */
|
| 33 | supportsPackage(pkg: Package, opts: MinimalLinkOptions): boolean;
|
| 34 | /**
|
| 35 | * This function must, given a specified locator, find the location where it
|
| 36 | * has been installed.
|
| 37 | *
|
| 38 | * Note that contrary to fetchers (that are allowed to return relatively
|
| 39 | * complex type of data source thanks to their filesystem abstractions), this
|
| 40 | * function is only allowed to return a path. That being said, the way this
|
| 41 | * path is interpreted is open to the package manager, though - in practice
|
| 42 | * it will be used on a ZipOpenFS, so you can return paths from within zip
|
| 43 | * archives.
|
| 44 | *
|
| 45 | * @param locator The queried package.
|
| 46 | * @param opts The link options.
|
| 47 | */
|
| 48 | findPackageLocation(locator: Locator, opts: LinkOptions): Promise<PortablePath>;
|
| 49 | /**
|
| 50 | * This function must, given a specified location on the disk, find the
|
| 51 | * locator for the package that owns it. This function is allowed to fail if
|
| 52 | * the location doesn't seem to be owned by any package covered by the
|
| 53 | * current linker, in which case it should return null.
|
| 54 | *
|
| 55 | * The main case where this function is called is when a postinstall script
|
| 56 | * for a third-party package calls another script of its. In this situation,
|
| 57 | * we must figure out who's making the "run" call, and we can't really rely
|
| 58 | * on anything else than the location on the disk to do so.
|
| 59 | *
|
| 60 | * @param location The queried location on the disk.
|
| 61 | * @param opts The link options.
|
| 62 | */
|
| 63 | findPackageLocator(location: PortablePath, opts: LinkOptions): Promise<Locator | null>;
|
| 64 | /**
|
| 65 | * This function must instantiate an Installer object that describes how to
|
| 66 | * install the packages on the disk. Check the Installer file for more
|
| 67 | * details on the installer design.
|
| 68 | *
|
| 69 | * @param opts The link options.
|
| 70 | */
|
| 71 | makeInstaller(opts: LinkOptions): Installer;
|
| 72 | }
|