/**
 * 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;
}
