UNPKG

pertain

Version:

Automated pub/sub across project dependencies. Run code from any installed package based on declarative rules in package.json

49 lines (48 loc) 1.94 kB
/** * A Node module that the consuming project (the one calling `pertain()`) has * declared in `dependencies` or `devDependencies`. These are the modules that * we check for the package property we're looking for. */ export default class ExplicitDependency { /** * Lazy-loading package.json data. */ private pkg; /** * Real path on disk of this module. */ modulePath: string; /** * Name of this package; for use in dependency detection. */ get name(): string; constructor(modulePath: string); /** * Returns true if this module has declared an explicit peer dependency on * the provided module name. Used to sort all pertaining modules into * dependency order. * * Why only a peer dependency? Because the consuming project doesn't want * `pertain()` to scan infinitely into the module tree; only first-level * dependencies can pertain. So the dependency order is only relevant to * the dependencies that the root project has directly declared. * * TL;DR if you're building an extension framework with `pertain()`, you * should require extensions to use `peerDependencies` when using other * extensions. Otherwise they're not guaranteed to run in the right order. */ dependsOn(name: string): boolean; /** * Returns a resolvable path to a JS module declared in this `package.json`, * at the JSON path supplied as `subject`. If no path exists, returns false. * * Example: If the subject is `"foo"`, AND `package.json` has a top-level * property `"foo": "./bar.js"`, then `this.pertains("foo")` will be * `"/path/to/this/module/bar.js"`. * * Dot notation lookup works: if the subject is `pwa.build`, then * `package.json`must have a top level `pwa` object with a `build` property. */ pertains(subject: string): string | false; toString(): string; }