import { AttributeDirectiveHandler, TagDirectiveHandler } from "./ng-directives";
export { AttributeDirectiveHandler, TagDirectiveHandler, defaultTagDirectiveHandlers, defaultAttrDirectiveHandlers } from "./ng-directives";
import { ControllerViewInfo, ControllerViewConnector, CtrlViewFragmentExtractor, ModelViewConnector } from "./controller-parser";
import { NgFilter } from "./filters";
export { ControllerViewInfo } from "./controller-parser";
/**
 * Configuration for a ng-typeview project.
 */
export interface ProjectSettings {
    /**
     * The path for the project on disk (root folder)
     */
    path: string;
    /**
     * Folders within the project to exclude from analysis
     * (for instance external JS libraries, the folder where
     * your typescript is compiled to javascript, and so on).
     */
    blacklistedPaths: string[];
    /**
     * List of angular filters to handle during the analysis.
     * You can use [[defaultNgFilters]], add to that list, or specify your own.
     */
    ngFilters: NgFilter[];
    /**
     * List of controller-view connectors to use.
     * [[defaultCtrlViewConnectors]] contains a default list; you can use
     * that, add to that list, or specify your own.
     */
    ctrlViewConnectors: ControllerViewConnector[];
    /**
     * Hardcoded controller/view connections that'll be added
     * to the ones which were autodetected through ctrlViewConnectors.
     * Useful in case it's too hard to parse some connections
     * from source.
     */
    extraCtrlViewConnections: ControllerViewInfo[];
    /**
     * List of model-view connectors to use.
     * These tie model files to views.
     * This allows to express non-controller models, such
     * as directive models for instance.
     * [[defaultModelViewConnectors]] contains a default list; you can use
     * that, add to that list, or specify your own.
     */
    modelViewConnectors: ModelViewConnector[];
    /**
     * List of tag-bound angular directives to handle during the analysis.
     * [[defaultTagDirectiveHandlers]] contains a default list; you can use
     * that, add to that list, or specify your own.
     */
    tagDirectives: TagDirectiveHandler[];
    /**
     * List of attribute-bound angular directives to handle during the analysis.
     * [[defaultAttrDirectiveHandlers]] contains a default list; you can use
     * that, add to that list, or specify your own.
     */
    attributeDirectives: AttributeDirectiveHandler[];
    /**
     * Controller view fragment extractors. For instance, you may have
     * view fragments present in your controllers, for instance ng-grid has
     * 'cell templates' which typeview can also type-check through this mechanism.
     * Extractors allows you to tell ng-typeview about those.
     */
    ctrlViewFragmentExtractors: CtrlViewFragmentExtractor[];
    /**
     * When resolving the scope for variables in the view, we prefix "$scope."
     * for all variables except those defined in the view. For instance, a
     * `ng-repeat` will define local variables. For these, we do not prefix with
     * "$scope.". 99% of the time, that works great.
     * One issue that can come up though, is if you have static fields for
     * instance. If you read `MyClass.MY_STATIC_FIELD`... That'll work in javascript
     * and angular, due to the TS->JS transpilation. But in ng-typeview, we
     * can't declare on the scope a field of type [class of MyClass], so that
     * field.MY_STATIC_FIELD would work.
     * So a workaround is to specify in your controller:
     * `import MyClass = api.MyClass;`
     * In that case, if you enable this `resolveImportsAsNonScope` option
     * (disabled by default), ng-typeview will not resolve
     * `MyClass.MY_STATIC_FIELD` as `$scope.MyClass.MY_STATIC_FIELD` anymore,
     * but as `MyClass.MY_STATIC_FIELD`. And since we copy the imports in the
     * viewtest, it should work.
     * But it's pretty messy, so we rather encourage you to avoid statics if
     * at all possible.
     */
    resolveImportsAsNonScope?: boolean;
}
/**
 * Will go through the views and controllers in the project folder and
 * generate viewtest typescript files to ascertain type-safety of the views.
 * NOTE: The function returns a promise but is not fully async: a good part of its
 * runtime is spend running synchronous functions.
 */
export declare function processProject(prjSettings: ProjectSettings): Promise<any>;