export interface ModuleResolutionConfig {
    /**
     * Folder names or directory paths where to find modules.
     *
     * **Note: This completely replaces the default `node_modules` lookup.
     * To keep `node_modules`, include it explicitly: `["node_modules", "{configDir}/store"]`**
     *
     * Absolute and relative paths can both be used, but be aware that they will behave a bit differently.
     *
     * A relative path will be scanned similarly to how Node scans for `node_modules`, by looking through the
     * current directory as well as its ancestors (i.e. `./node_modules`, `../node_modules`, and on).
     *
     * With an absolute path, it will only search in the given directory.
     *
     * Template variables:
     * - `{configDir}` can be used to build paths relative to the configuration directory.
     *   For example: `{configDir}/store` resolves to an absolute path pointing to the `store`
     *   subdirectory within the directory containing the configuration file.
     *
     *   Restrictions:
     *   - The `{configDir}` template must appear at the beginning of the path
     *   - Valid: `{configDir}/store`, `{configDir}/components`
     *   - Invalid: `some/path/{configDir}` or `{configDir}/{configDir}/nested`
     */
    modules?: string[];
    /**
     * Array of module names to enforce consistent resolution using the application's module resolution strategy.
     *
     * Prevents multiple instances of the same package when dealing with duplicate dependencies
     * that may arise from package hoisting or linked dependencies in monorepo setups.
     *
     * Example: ["react", "lodash"] ensures these packages are always resolved using
     * the same resolution path that the application would normally use.
     *
     * This settings will be ignored for inlinedDependencies.
     */
    dedupe?: string[];
}
//# sourceMappingURL=ModuleResolutionConfig.d.ts.map