Missing Compiler Options

[csnover]

I’ll try to send a patch if nobody else gets to it first.

Admin comments:

Currently Detected missing ones:

• outDir
• noEmitOnError
• preserveConstEnums
• suppressImplicitAnyIndexErrors

[basarat]

@csnover would you like to be a member for this repository. You don't have to do anything for it. I've seen your work on Microsoft/TypeScript and would like your completely optional input when / if you feel like it.

[basarat]

@csnover This was intentionally lazy on my part. I wanted to get the ball rolling and not focus on getting compiler options parity.

[basarat]

I've made copy edits to the issue to track all the ones people need.

[csnover]

@basarat Whatever you would like is fine by me! :) I will talk to you before I start committing any changes to master.

[basarat]

@csnover awesome. Welcome to the team!

[csnover]

@basarat I put a commit on the patch-48 branch that passes all possible compiler options directly through to TypeScript services. It’s designed with the idea that in the future we will just use the tsconfig.json parser straight from TypeScript itself.

I’ve tested outDir, it works, and the other properties are picked up correctly as well. The conversion of outDir to an absolute path might be more appropriate within the compiler host (using getCompilerOptions and then resolving it there), since otherwise right now I think we’re going to sometimes write an absolute path back to tsconfig.json. I suppose the other option is to reverse the transform in the complementary tsToRaw function.

This patch doesn’t collapse case of the keys, per my recommendation in microsoft/TypeScript#1933, and actually shows deprecation warnings on any lower-case keys that were previously specified in the CompilerOptions interface, just so it doesn’t silently break for anyone.

So, I wanted you to get a review from you for that reason. Hopefully through my words and this code I am successful at convincing you of the benefits of the simple (code-wise) and highly idiomatic nature of this approach versus the complex and non-idiomatic case folding approach.

But also, another bigger problem (which is why I did not make a PR): for some reason I am having trouble getting --preserveConstEnums to actually work on the compile. grunt-ts doesn’t list it as a supported option, and it’s not in the Gruntfile, but even when I run tsc --preserveConstEnums directly, the compiler is still converting the ts.ModuleKind and ts.ScriptTarget enums into numbers. I am curious how you have been building these files without that problem? Let me know so I can actually make it work here too.

Thanks!

[basarat]

actually shows deprecation warnings on any lower-case keys that were previously specified in the CompilerOptions interface, just so it doesn’t silently break for anyone.

👍 good call. Thanks!

I am curious how you have been building these files without that problem?

I've been compiling with problem :) different output from grunt vs. language service. I've been meaning to fix it.

So, I wanted you to get a review from you for that reason. Hopefully through my words and this code I am successful at convincing you of the benefits of the simple (code-wise) and highly idiomatic nature of this approach versus the complex and non-idiomatic case folding approach.

Go for it! thanks!

[csnover]

I've been compiling with problem :) different output from grunt vs. language service. I've been meaning to fix it.

Oh, I see, the language services do emit them as expressions. Interesting. I wonder why the command-line compiler won’t… well, anyway, that at least gets me compiling the same as you.

Go for it! thanks!

OK, committed.

[csnover]

Opened a thing about preserveConstEnums, microsoft/TypeScript#1934

[nycdotnet]

FYI: I just added support for --preserveConstEnums to grunt-ts in TypeStrong/grunt-ts#206 . I will merge next week if I don't hear anything (or "someone else" can merge it for me if they're happy with it).