Support tsconfig.json

[basarat]

More about this coming change : microsoft/TypeScript#1667

Need ideas. Perhaps a project target option to point to tsconfig.json file will cause the src / other compiler options to be driven by tsconfig.json?

[SergioMorchon]

+1, need this!

[getvega]

+1 !

[nycdotnet]

I've been thinking about this. There are a few different ideas I've had. They are not necessarily mutually exclusive.

Idea 1: Provide tsconfig.json support similar to the existing vs support - i.e. whatever is in tsconfig.json gets passed to tsc using the normal switches, but allow overrides in the Gruntfile.

Example for Idea 1:

{
  "compilerOptions": {
    "module": "commonjs",
    "noImplicitAny": true
  }
}

// this would take the noImplicitAny setting from the tsconfig.json,
//  but override the module setting.
ts: {
  default : {
    project: "./tsconfig.json",
    options: {
      module: "amd"
    }
  }
}

Idea 2: Management of files property - and potentially filesGlob. One of the best things about atom-typescript is how it manages the files property via filesGlob. I wonder if we can (or should) build in copying the filesGlob to tsconfig.json; or perhaps even doing the expansion in grunt-ts and updating files.

ts: {
  default : {
    project: "./tsconfig.json",
    // What should happen here?  Should we take the results of `src` expansion
    //  and update the `files` property in tsconfig.json?
    src: ['./src/**/*.ts','./tests/**/*.ts']
  }
}

Should there perhaps be a new parameter in grunt-ts like updateTSConfig: { compilerOptions: true, filesGlob: true, files: true }?

I would hesitate to make this happen by default because tsconfig.json is a singleton - so if we did allow grunt-ts to update the tsconfig.json we'd probably have to recommend that only a single target be configured to do that to avoid churn (not sure we could efficiently validate that or that it would be helpful to do so).

Idea 3: Just call TSC and use the new --project switch and let tsc do what it wants - I am not sure this is such a good idea as it abandons the useful stuff grunt-ts does.

Just some ideas. Would love feedback.

[getvega]

I would lean towards your Idea 2 with updateTSConfig as I am using SublimeText TS which has quite limited tsconfig.json support ftm.
IMHO having grunt-ts centralize the fileglob settings seems like the way to go, as that would mimic what we already do with other preprocessors.

[basarat]

👍 on idea 2. Recommend:

ts: {
  default : {
    project: "./tsconfig.json",
    // If specified overrides `files` setting in project. Otherwise just use `files` setting. 
    src: ['./src/**/*.ts','./tests/**/*.ts']
  }
}

People that are using filesGlob should be able to just copy that setting into src. Otherwise files will be kept up to date by atom-ts. Till filesGlob becomes standard its more of just an atom-ts-filesGlob-hack thingy. For grunt-ts: src is the appropriate point for this hack :)

[ryanwalls]

Would really love to have this feature.

[aikrez]

+1

[gilamran]

+1

[vvakame]

👍

[nycdotnet]

OK folks - here's my design. I should have time to code this tomorrow and Friday, so please provide any comments soon. Thanks for your patience.

Proposal for tsconfig.json Support

Grunt-ts supports using a tsconfig.json file. Here are some example Gruntfile initConfig sections:

Use all settings from the specified tsconfig.json file including files and compilerOptions (path to the tsconfig.json file is relative to Gruntfile.js). This will use filesGlob, if present, but not update it if a different glob is optionally passed to grunt-ts. It is not required to pass src or files to grunt-ts if tsconfig is passed. The tsconfig property should function correctly as either a task option or a target property.

grunt.initConfig({
  ts: {
    default: {
      tsconfig: true   // Value must be a string referencing a file path such as "./somefolder/tsconfig.json", OR a truthy value to use the 'tsconfig.json' in same folder as Gruntfile.js
    }
  }
});

If more control is desired, you may pass tsconfig as an object:

grunt.initConfig({
  ts: {
    default: {
      tsconfig: {
        tsconfig: './SomeOtherFolder/tsconfig.json',  // optional - if absent will default to 'tsconfig.json' in same folder as Gruntfile.js.  If a folder is passed, will use tsconfig.json in that folder.
        ignoreFiles: false, // optional - default is false.  If true, will not inlcude files in `files` array from `tsconfig.json` in the compilation context.
        ignoreSettings: false, // optional - default is false.  If true, will ignore `compilerOptions` from `tsconfig.json` (instead using grunt-ts settings from Gruntfile.js)
        overwriteFilesGlob: false, // optional - default is false.  If true, will overwrite the contents of the `filesGlob` array with the contents of the `src` glob from grunt-ts.
        updateFiles: true, // optional - default is true.  Will maintain the `files` array based on the files found in `filesGlob`. (Note - If there is a `filesGlob` element, grunt-ts will only add/remove files that match it in the `files` array - not files found in any glob from `src`.  This is relevant if `overwriteFilesGlob` is false (the default).  )
        passThrough: false // optional - default is false.  If passThrough is set, grunt-ts will run TypeScript (tsc) with the specified tsconfig passing the `--project` option only (and anything in additionalFlags).  This provides support for custom compilers with custom implementations of tsconfig.json.
      }
    }
  }
});

Important notes:

• Globs in filesGlob in tsconfig.json are relative to the tsconfig.json NOT the Gruntfile.js.
• tsconfig has a restriction when used with files in the Grunt task configuration: overwriteFilesGlob is NOT supported if files has more than one element. This will abort compilation.
• If files is absent in tsconfig.json, but filesGlob is present, grunt-ts will create and update the files array in tsconfig.json as long as updateFiles is true (the default). Since files will be created in this scenario, the exclude array will be ignored.
• If files AND filesGlob are absent in a tsconfig.json file that is "valid", then grunt-ts will include ./**/*.ts and ./**/*.tsx (relative to the tsconfig.json) in the compilation. In this case, entries in exclude will be considered, and grunt-ts will not create a files array in tsconfig.json.

General "Happy Path" processes providing support for using an editor like Notepad++ or Sublime that does NOT maintain the tsconfig.json

Basic tsconfig: true

grunt.initConfig({
  ts: {
    default : {
      tsconfig: true
    }
  }
);

• Grunt-ts will open and parse the ./tsconfig.json. If the tsconfig.json file does not exist it will be created with the defaults and a filesGlob that finds all .ts files excluding node_modules. If there is a parse error, compilation will be aborted with an error.
• Since in this scenario updateFiles is true (via default), if a filesGlob element is present in tsconfig.json, Grunt-ts will attempt to match all files with it and then update files in tsconfig.json with the result and save it.
• The files in the (updated) files array will be added to the grunt-ts compilation context.
• The options in compilerOptions will be used.

Basic "passThrough"

If passThrough is set, grunt-ts will run TypeScript (tsc) with the specified tsconfig passing the --project option only (and anything in additionalFlags). This provides support for custom compilers with custom implementations of tsconfig.json.

  grunt.initConfig({
    ts: {
      default : {
        tsconfig: {
          passThrough: true
        }
      }
    }
  );

• Grunt-ts will open and parse the ./tsconfig.json. If the tsconfig.json file does not exist it will be created with the defaults and a filesGlob that finds all .ts files excluding node_modules. If there is a parse error, compilation will be aborted with an error.
• Since in this scenario updateFiles is true (via default), if a filesGlob element is present in tsconfig.json, Grunt-ts will attempt to match all files with it and then update files in tsconfig.json with the result and save it.
• Grunt-ts will run tsc --project .
• Note: if a string value is specified for tsconfig.tsconfig and tsconfig.passThrough is also present, the value of tsconfig must be a directory. In that case, tsc will search for a tsconfig.json file.

Scenario: tsconfig.json is set up for "dev", grunt-ts "release" task is set up for production.

  grunt.initConfig({
    ts: {
      options: {
        tsconfig: true
      }
      release : {
        options: {
          removeComments: true
        }
      },
      dev : {}
    }
  );

• Grunt-ts will open and parse the ./tsconfig.json. If the tsconfig.json file does not exist it will be created with the defaults and a filesGlob that finds all .ts files excluding node_modules. If there is a parse error, compilation will be aborted with an error.
• Since in this scenario updateFiles is true (via default), if a filesGlob element is present in tsconfig.json, Grunt-ts will attempt to match all files with it and then update files in tsconfig.json with the result and save it.
• Let's assume that removeComments is false in tsconfig.json. When the release target is run, the comments will be removed. When the dev target is run, the comments will be preserved.

Scenario: tsconfig.json is set up for a common set of files, but we would like to selectively include different sets of files in the compilation context based on the build config.

  grunt.initConfig({
    ts: {
      options: {
        tsconfig: true
      }
      bigBuild : {
        src: './OtherStuffNotInThesmallBuild/**/*.ts'
      },
      smallBuild : {}
    }
  );

• Grunt-ts will open and parse the ./tsconfig.json. If the tsconfig.json file does not exist it will be created with the defaults and a filesGlob that finds all .ts files excluding node_modules. If there is a parse error, compilation will be aborted with an error.
• Since in this scenario updateFiles is true (via default), if a filesGlob element is present in tsconfig.json, Grunt-ts will attempt to match all files with it and then update files in tsconfig.json with the result and save it. Note that the files section is only ever updated with files found via the filesGlob inside the tsconfig.json - grunt-ts will NOT add files found via an src or files glob on the ts task or current target.
• When the ts:bigBuild target is active, grunt-ts will pass all files found in the files array from tsconfig.json first, and then all files found when evaluating the src glob on ts:bigBuild (eliminating duplicates).
• When the ts:smallBuild target is active, grunt-ts will pass all files found in the files array from tsconfig.json only since there is no src glob on ts:smallBuild.

Support for vs property

This feature can be used with the vs keyword. Any settings found in tsconfig.json will override any settings found in the Visual Studio project file. Any files referenced in the Visual Studio file that are not also referenced in tsconfig.json will be included in the compilation context after any files from tsconfig.json (any files from src but not in vs or tsconfig will be included after that). The order of the files in tsconfig.json will override the order of the files in the VS project file.

[basarat]

Looks good 👍

[johnman]

Hi just a thought.

This may already be covered but I'm not sure after reading through the proposal.

From what I've read you can have a tsconfig file and decide to use it or override settings when compiling using grunt-ts.

I like the fact that in grunt you have the option of overriding settings based on a context (i.e. you could either have a dev or release config section in grunt-ts or you could have a property <%= my.property %> which can be overridden based on a flag passed to grunt for example.

Since there can only be one primary tsconfig.json file could we have a flag that generates this file or updates it?

i.e. grunt settings -> grunt-ts -> tsconfig.json

That way my primary build config is in grunt and tsconfig is generated to work well with IDEs etc.

People may have a watch that triggers grunt-ts on modification of ts files and this could refresh the tsconfig file so you're ide is in sync.

Thoughts?

[nycdotnet]

It sounds like you're asking for an overwriteCompilerOptions feature. This would default to false, but if true it would update the tsconfig.json 's compilerOptions section with the configuration available in the Gruntfile. Is that what you're asking for?

If so, I'll have to think about it. My thought about this feature is that the tsconfig.json should be set up to support your IDE/the TypeScript language service, and that grunt-ts should be for "full builds" or "special partial builds" only. If you're worried about having to repeat yourself, just put all of the appropriate config to make your IDE happy in the tsconfig.json, and only put overrides in the Gruntfile. If things are set up that way, I don't see the value in supporting an overwriteCompilerOptions feature.

Please let me know if I'm missing the point.

[gilamran]

I think that the tsconfig.json should always override grunt-ts compiler setting.
Actually the tsconfig.json is good for the IDE, your IDE will never "understand" the compiler setting that you have on your grunt-ts...
On the day to day you will let the IDE see the tsconfig.json and "understand" the project's settings, and in your build process you'd want to override some setting that exist in the tsconfig.json.

[johnman]

@nycdotnet Hi yeah I was thinking something along those lines. I was also thinking of the src files.

E.g. Grunt-ts has a pattern of files to compile and one of those is similar to a vendor.d.ts file to take into account thirdparty modules I am importing.

There should be no need for me to add /// now that tsconfig exists.

This setting exists in my settings of my gruntfile which I can override by pointing to different settings files etc.

I was hoping for a flag that would generate a tsconfig and keep it in sync with my grunt build (with this file in mind).

e.g. from your description above:

Grunt-ts will open and parse the ./tsconfig.json. If the tsconfig.json file does not exist it will be created with the defaults and a filesGlob that finds all .ts files excluding node_modules. If there is a parse error, compilation will be aborted with an error.
Since in this scenario updateFiles is true (via default), if a filesGlob element is present in tsconfig.json, Grunt-ts will attempt to match all files with it and then update files in tsconfig.json with the result and save it.

What if you grunt-ts had a filesGlob pattern specified...could it use that instead of a default that finds all .ts files?

This way they can specify a pattern in one place and it would apply to both (I know this happens if you have the settings in your tsconfig and have grunt-ts use that...is just that other grunt tasks also use this setting e.g. grunt-contrib-watch and that would get out of sync if you are changing the file pattern in tsconfig).

[bgever]

If more control is desired, you may pass tsconfig as an object:

I like that you can override with another tsconfig.json file in a different location. For instance, in our case we have a root Web App, and an Admin MVC Area. Both share code, but due to the variations in the include patterns, they generate different bundles with -out. This way we can specify two grunt subtasks for each bundle. 👍

[nycdotnet]

What if you grunt-ts had a filesGlob pattern specified...could it use that instead of a default that finds all .ts files?

@johnman This would be supported with the design above. I will add an explicit scenario to explain.

[nycdotnet]

OK added another scenario at the end.

Sorry this has taken so long. There's a lot going on in my personal life at the moment - I hope this will be available in two or three weeks.

[nycdotnet]

I have created PR #275 for this which is still very much a work-in-progress. It's a significant refactoring that will fix several longstanding issues with grunt-ts options resolution, add many fast unit tests, and consolidate the vs and (new) tsconfig code. It should be ready for testing in a few days assuming I don't have any personal emergencies.

Thanks for your patience, all. I will really appreciate your assistance with testing once the 5.0.0 beta is available. :-)

[nycdotnet]

Hi All,

Well, the initial refactoring work took much longer than expected, but #275 now has all unit tests passing. It's up to 33 changed files with 3,333 additions and 1,710 deletions; granted a lot of these are refreshing definition files, but this is still a lot of new code. The good news is that grunt-ts should be a lot cleaner to work on now going forward and has way more tests and a good way to hook in fast unit tests that don't require actually running Grunt and TypeScript like before.

I'm ready to get started on the tsconfig.json support and I'm assuming it should actually be the easy part as I got the old "vs" functionality working in just a few hours with the new optionsResolver system. Again thanks for your patience. I'm fairly confident that the beta should be out by the end of the week, but I will need your help to test everything.

Thanks!

[SergioMorchon]

@nycdotnet Thanks a lot!!!

[gilamran]

@nycdotnet, what's planned for the configuration overrides? will the tsconfig.json override the grunt-ts task configuration of the other way around?

As mentioned before I think that the grunt-ts configuration should override the tsconfig configuration. this is really important because the tsconfig.json is very useful for the IDE and the grunt-ts for the build time.

[nycdotnet]

Yes the gruntfile will override the tsconfig so build time can be different than dev time.

Full spec several posts back in this thread. See "Proposal for tsconfig.json Support".

[nycdotnet]

Quick update: I have the basic scenario essentially working and expect to release a beta later today.

[nycdotnet]

Hooray! grunt-ts 5.0.0-beta.1 now available on npm.

PLEASE HELP BY TESTING Version 5 is a major refactoring in addition to the tsconfig.json support, so I will appreciate your assistance.

Features not yet implemented: ignoreSettings, overwriteFilesGlob, updateFiles, passThrough. All but passThrough should make it into 5.0 final. passThrough will likely be in a later patch.

Please note that I don't think templates are going to fully work yet, though they should probably not be worse than at current. Thanks very much!

[nycdotnet]

I've published [email protected] which resolves the issues identified by @vvakame:

• Templates should now work as expected.
• grunt-ts will warn if tsconfig is specified on the task or target options object.

Would you please test again? Thank you!!

[nycdotnet]

FYI: [email protected] is now out which adds support for the passThrough feature and contains a few fixes. I believe all that remains is ignoreSettings, overwriteFilesGlob and updateFiles support.

Any testing or feedback is appreciated. Thank you.

[lhecker]

Let's say my Gruntfile.js uses this very simple task:

ts: {
    default : {
        tsconfig: true,
    },
},

and my tsconfig.json looks like this:

{
    "compilerOptions": {
        "target": "es6",
        "sourceRoot": "src",
        "outDir": ".tmp",
        ...
    },
    "filesGlob": [
        ...
    ],
    "files": [
        ...
    ]
}

Am I doing something wrong if all the resulting .js and .js.map files are still placed in the src instead of the .tmp folder, or is this feature not yet implemented?

[nycdotnet]

I think you've specified it correctly. Are you using [email protected] from last night? Do you get any warnings on the command-line? Would you mind adding verbose:true under the ts:default entry and letting me know which switches were passed?

[nycdotnet]

Nevermind - there is indeed an issue with pulling outDir (and probably out) from the tsconfig. Thanks for finding this! Will fix presently.

[lhecker]

Yep I'm using the [email protected] together with typescript v1.6.0-dev.20150825.

Running "ts:default" (ts) task
Compiling...
Cleared fast compile cache for target: default
### Fast Compile >>src/...
...
### Fast Compile >>typings/...
...
Using tsc v1.6.0-dev.20150825
"C:\projects\airwatchconnector\src\..." ... "C:\projects\airwatchconnector\typings\..." ... --sourcemap --newLine LF --target ES6 --sourceRoot ./src

It seems the outDir member variable is not passed as --outDir to tsc.

Edit: Well... Thanks for caring about this! 😃

[nycdotnet]

I believe [email protected] should resolve this issue. Please let me know. Thanks for testing!!

[lhecker]

Yep. It's fixed, @nycdotnet. 😃

[nycdotnet]

Excellent!

[vvakame]

I tried [email protected].
but it is not works expectedly.
in [email protected] has --init options.
it generate above tsconfig.json.

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es3",
        "noImplicitAny": false,
        "outDir": "built",
        "rootDir": ".",
        "sourceMap": false
    },
    "exclude": [
        "node_modules"
    ]
}

grunt-ts is not pass through configfile to tsc?
FYI: https://github.com/Microsoft/TypeScript/blob/4a85546f946f0cee28f77feaaa96d1c0797de09e/src/compiler/commandLineParser.ts#L475
https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/tsconfig.json#L17-L19

[nycdotnet]

Those options should all work except exclude. I'll look into it. Thank you.

[mattoni]

I seem to be having an issue getting this working on [email protected].

My gruntfile.js looks like this:

        ts: {
            default: {
                tsconfig:'app/ts/tsconfig.json',
                out: "app/js/compiled-ts.js",
                options: {
                    sourceMap: true,
                    declaration: false,
                    sourceRoot: '../../app/ts/'
                }
            }
        },

and my tsconfig is just empty JSON ({}).

I get the following error when I try and compile:

TypeError: Cannot use 'in' operator to search for 'declaration' in undefined

Sorry if I'm making a simple mistake, I really would like to stop using reference files and move to the tsconfig structure.

Thanks!

[nycdotnet]

Not a mistake - i just hadn't anticipated someone passing in an empty object in their tsconfig. Can you add a compiler options empty object and an empty files array (see above for samples - typing on my phone) and it should work with the grunt settings. Then you can start transitioning over. Note that the filesglob feature isn't implemented yet in this PR so you may have to manage files manually for now.

[nycdotnet]

@vvakame どうもありがとうございます。 I forgot that if files is missing that tsconfig.json compiles *.ts and *.tsx. I have added these rules to the specification:

• If files is absent in tsconfig.json, but filesGlob is present, grunt-ts will create and update the files array in tsconfig.json as long as updateFiles is true (the default). Since files will be created in this scenario, the exclude array will be ignored.
• If files AND filesGlob are absent in a tsconfig.json file that is "valid", then grunt-ts will include ./**/*.ts and ./**/*.tsx (relative to the tsconfig.json) in the compilation. In this case, entries in exclude will be considered, and grunt-ts will not create a files array in tsconfig.json.

I will implement them soon. Thank you again for the report.

@AlexanderMattoni - your issue is resolved in my local code and will be fixed in the next beta.

[nycdotnet]

Hello again, All.

I have resolved the issues reported by @vvakame and @AlexanderMattoni , and completed the implementation of the tsconfig support. I believe that it is now feature complete.

There's a few little things I need to clean up and I still need to merge-in the docs, but I would greatly appreciate it if you would give [email protected] a try. It should be on npm now.

I expect that this will be final next week barring any major issues. Thank you so much!!

[escardin]

I'm having trouble with passthrough working:
Gruntfile:

ts:{
        build:{
            tsconfig:{
                passThrough:true
            }
        }
    }

tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "noImplicitAny": true,
    "removeComments": true,
    "preserveConstEnums": true,
    "outDir": "build/tmp/grunt/",
    "rootDir":"src/main/webapp",
    "sourceMap": true,
    "sourceRoot":"src/main/webapp",
    "target":"es5",
    "listFiles":true
  },
  "exclude": [
    "build",
    "coverage",
    "node_modules",
    "typings"
  ]
}

This works fine if I run tsc directly, and works okay if I remove passthrough and instead just pass true, but is extremely slow (tsc takes seconds, grunt ts:build takes a minute). I suspect it is not handling the exclude properly.

Tested with tsc 1.6.2 and 5.0.0-beta.5"

[nycdotnet]

Thanks for the report. Can you run it grunt with the --verbose switch and tell me what command line is passed into tsc? Can you then run that command-line manually and let me know if the performance is the same or not? With passThrough it should not technically be different, but there could be a bug.

[escardin]

grunt ts:build --verbose (ts:{build:{tsconfig:true}})

Running tasks: ts:build

Running "ts:build" (ts) task
Verifying property ts.build exists in config...OK
File: [no files]
Compiling...
### Fast Compile >><files from src/main/webapp...>
Using tsc v1.6.2
<complete paths to files from src/main/webapp> --removeComments --noImplicitAny --preserveConstEnums
--target ES5 --module commonjs --outDir build/tmp/grunt/

<compile errors>

TypeScript compilation complete: 1.48s for 40 typescript files

Done, without errors.


Execution Time (2015-09-24 16:23:47 UTC)
loading tasks        5ms  0%
ts:build        1m 51.5s  100%
Total 1m 51.5s

When I tried the command line it output, it took ~2s.

grunt ts:build --verbose (ts:{build:{tsconfig:{passThrough:true}}})

Running tasks: ts:build

Running "ts:build" (ts) task
Verifying property ts.build exists in config...OK
File: [no files]
No files to compile

Done, without errors.


Execution Time (2015-09-24 16:27:20 UTC)
loading tasks   5ms   31%
ts:build       11ms  69%
Total 16ms

date;tsc;date

$ date;tsc;date
Thu Sep 24 12:28:24 EDT 2015
<compile errors>
<files it is compiling>
Thu Sep 24 12:28:26 EDT 2015

If I were to guess, it's not using the exclude section properly and it's going through all of my other files.

[eweiss1979]

Using grunt-ts 5.0.0-beta.5 with typescript version 1.6.2

I want grunt-ts to compile my typescript into 1 js file. I also want it to use the settings in my tsconfig.json file in which I set the location of my app and typings with filesGlob setting.

I need the compliled js file to be put into a wwwroot publishing directory with sourcemaps back to my src directory.

gruntfile.js

        ts: {
            default: {
                tsconfig: true,
                out: "wwwroot/app/compiled-ts.js",
            }

tsconfig.json

{
    "compilerOptions": {
        "noImplicitAny": false,
        "noEmitOnError": true,
        "removeComments": false,
        "sourceMap": true,
        "target": "es5"
    },
    "filesGlob": [
        "src/app/**/*.ts",
        "typings/**/*.d.ts"
    ]
}

Couple of things is happening. One grunt-ts wants to modify my tsconfig.json with a files section. I don't really want this.

Also I'm not getting the compiled-ts.js created . It is still generating multiple js files for each ts file.

[nycdotnet]

@eweiss1979 It appears that the TypeScript team implemented a breaking change in 1.6.2 for some reason and changed --out to --outFile. I'll log this as a separate issue and address this in v5.0.1.

[nycdotnet]

@escardin I've implemented an optimization that avoids adding directories to the glob that will be excluded as per the tsconfig.json file. This should resolve the performance issue you're experiencing - please let me know.

[nycdotnet]

I've released [email protected] which should address these comments.

I will work on closing out the remaining chores later today and hopefully will release 5.0.0 officially later today unless I hear of something bad.

@eweiss1979 - FYI: The default behavior of grunt-ts is to maintain the files array in your tsconfig.json file. If you wish to not have this happen, set updateFiles to false. See here: #202 (comment) I'll update the main docs later today.

[basarat]

TypeScript team implemented a breaking change in 1.6.2 for some reason and changed --out to --outFile

@nycdotnet I asked the same question. I just chose to treat them the same way : microsoft/TypeScript#5107 (comment) the difference is out is relative to cwd and outFile is relative to tsconfig.json

I treat both relative to tsconfig.json ... I think most people understand out to be relative to tsconfig.json ... why would cwd change the intent of the contents of tsconfig.json! 🌹

[nycdotnet]

I saw that. Thanks Bas.

Folks - I'm adding back in some warnings that were removed during the refactoring. I'll release as soon as that work is done barring any reports of problems. Thanks!

[escardin]

@nycdotnet You did fix my issue, sorry for the delay.