configurationPath option for programmatic API.

[jkillian]

With more features coming to tslint.json files, such as the rulesDirectory option and the extends option, it becomes harder and harder for third-party tools that wrap TSLint to properly load configurations themselves. (See #1007 for example.)

The easiest and cleanest solution (that I can think of) for this is to change the Linter options API.

Current:

export interface ILinterOptions {
    configuration: any;
    formatter: string;
    formattersDirectory: string;
    rulesDirectory: string | string[];
}

Option 1

export interface ILinterOptions {
    configuration: ITSLintConfig | string;
    formatter: string;
    formattersDirectory: string;
    rulesDirectory: string | string[];
}

Option2

export interface ILinterOptions {
    configuration?: ITSLintConfig;
    configurationPath?: string;
    formatter: string;
    formattersDirectory: string;
    rulesDirectory: string | string[];
}

If a path to a configuration is provided (instead of passing a configuration object directly), TSLint would handle all responsibilities such as resolving rules directories, resolving extends clauses, etc. If a configuration object is passed directly, the third-party tool would have to take care of these tasks.

[unional]

Currently in my PR I have the config:

export interface ConfigFile { // will rename to ITSLintConfig
    extends: string | string[];
    rulesDirectory: string | string[];
    rules: any;
}

Likely it doesn't match what you have in mind based on your snippets.
What do you envision? I can adjust the PR accordingly.

[jkillian]

IConfigFile sounds good to me! In fact, your definition looks correct. The duplication of fields like rulesDirectory seems strange at first, but it's just how it has to be for historical reasons. tslint.json files used to only specify what rules to use, and when using TSLint programmatically, this data was passed as the configuration member of ILinterOptions. You could also then pass things like rulesDirectory separately.