Configuration file support

[urish]

Once #27 is merged, or #29 is implemented, it will make sense to have some configuration file to toggle these behaviors. A few more things the user may want to configure:

• Whether to instrument arrow functions
• Whether to detect the shapes of objects (once Expand object? #19 is implemented)

And I am pretty sure we will have more down the road. This also paves the road to adding experimental features, which will be turned off by default, but available for adventurous users.

[zoehneto]

I'm thinking about implementing this since I just switched my build to typewiz-webpack and I really want to take advantage of the newer features which aren't enabled by default. I imagine the following:

Config File

typewiz.json

• options from IInstrumentOptions
• options from ICompilerOptions
• options from IApplyTypesOptions

the result would look something like:

{
    /**
     * If given, all the file paths in the collected type info will be resolved relative to this directory.
     */
    rootDir?: string;

    /**
     * Path to your project's tsconfig file
     */
    tsConfig?: string;

    // You probably never need to touch these two - they are used by the integration tests to setup
    // a virtual file system for TS:
    tsConfigHost?: ts.ParseConfigHost;
    tsCompilerHost?: ts.CompilerHost;

    instrumentCallExpressions: boolean;
    instrumentImplicitThis: boolean;

   /**
     * A prefix that will be added in front of each type applied. You can use a javascript comment
     * to mark the automatically added types. The prefix will be added after the colon character,
     * just before the actual type.
     */
    prefix?: string;
}

Plugin Integration

typewiz-webpack

We can pass the config path to the loader:

use: [
    {
        loader: 'typewiz-webpack',
        options: {
            config: 'some/path/typewiz.json'
        }
    },
    'ts-loader'
],

and to the plugin:

plugins: [
    new TypewizPlugin('some/path/typewiz.json')
]

typewiz-node

We could pass the config path to the normal command or detect it automatically, the former might be difficult when using it with mocha though.

Internal Handling

This leaves the question what the config file actually does. Do we want a central config file handling in typewiz (with instrument() and applyTypes() using this config object) or should the individual plugin interpret the config file and pass the correct options to the existing functions? If the former is chosen, what does this mean for people using the api directly?

[urish]

Great write up @zoehneto, pretty much summarizes my thoughts :)

As for the internal handling part, I see two approaches:

1. Divide the config file into sections, e.g.

{
  "common": {
     "rootDir": "...",
     "tsConfig": "..."
  },
  "instrument": {
     "instrumentCallExpressions": true,
     "instrumentImplicitThis": true
   },
   "applyTypes": {
      "prefix": "TypeWiz |"
   }
}

Then you can just pass the appropriate section to each of the functions, merged with the "common" section.

Another approach would be to create helper functions that only return the relevant part of configurations for each of the functions, e.g. applyTypesConfig() that will get a typewiz configuration (in any format we decide on), and return the relevant options for applyTypes. This will allow much more flexibility in the config file format.

Thoughts?

[zoehneto]

I like the splitting into different sections from approach 1 since it nicely represents the stages of the typewiz process and also makes it more clear what options do / where they are used ('prefix' by its self doesn't tell you when its used). But we should probably still create the helper functions so we can decouple the config file properties from the options passed to the individual functions.

[zoehneto]

Basic config file support is merged, here are the tasks left for full support:

• Add support for applying types with config to typewiz-webpack (potentially as part of CLI [RFC] #53 )
• Update urish/typewiz-webpack-demo
• Add schema to Schema Store for editor support
• Update typewiz-webpack and typewiz-node dependency on typewiz-core to the correct (published) version
• Document typewiz.json

[zoehneto]

I created a PR for Schema Store at SchemaStore/schemastore#433

[zoehneto]

I just submitted a PR for urish/typewiz-webpack-demo. That means that once all relevant PRs are merged this issue is resolved.