Conditional Compilation?


Reading the spec, I don't see any mention of preprocessor directives. It's nice, in my experience, to be able to define additional code for debug purposes, such as console logging, or other types of runtime checks that you'd like to omit in a minified/release

Just simple support for #if would be nice.
Closed Jan 24, 2013 at 8:29 PM by jonturner
As rictic points out, this is better handled outside of the compiler, using build scripts and/or a more JavaScript-style approach.

In JavaScript, it's quite common to use techniques like AMD to configure projects for particular environments or feature sets. As AMD and module loading is already supported, this is generally our preferred solution to project configuration.


jpoehls wrote Oct 5, 2012 at 5:53 PM


Conditional code for console logging and debugging would be a huge help. It is far to easy for that code to slip into production right now.

pstj wrote Oct 5, 2012 at 7:55 PM

For stripping debug calls? Really? One can always use another tool to strip debug calls/symbols.

What conditionals will be great at is enabling/disabling module inclusion and targeting specific run environments (consider 'legacy browsers' build and 'modern browser' build). Much more useful than removing console.log calls!

diegovilar wrote Oct 11, 2012 at 4:00 PM

Conditional compilation would be awesome. For code that needs extra-checking in development/debug time, it's absolutely necessary. We already use this through Ant with extended tasks before the build process, and it's just as useful as in any other language in VS, just like VB and C# have through comment directives that have access to constants for deciding which code to include in the build.

We're gonna use it, either by modifying the build steps to pre-process the source using a 3rd party tool and output them to a temporary folder and then doing the actual build task over that, or through the TSC compiler itself.

Through the TSC compiler is more clean, direct and elegant, as we don't have to resort to 3rd party tools.

ertant wrote Oct 28, 2012 at 2:34 PM


Conditional directives can be very useful for javascript environment with lack of debugging.

williamforney wrote Nov 29, 2012 at 11:25 AM

It would be great if all the conditional code that was previously in jsbuild.dll in the old ASP.NET project was supported in TypeScript. This would let you use preprocessor directives to include files, do conditional includes of lines, and declare variables that affect the same. The main feature I would like is an include comment that would let you chunk up your files a bit better.

rictic wrote Jan 7, 2013 at 12:21 AM

This feature is something that other tools can handle. For example you can by default include noop versions of all of your debug functions and check once at runtime that you're running in development mode and swap in the slow functional versions.

Or, in your build script you could include a different version of a debug.ts file when you're in dev mode vs production mode.

I vote against this feature.

MgSam wrote Jun 12, 2013 at 4:39 PM

I disagree with the closure of this issue. It's a much bigger pain to edit build scripts than to slip in an #if statement. You also lose the editor and language support this way. It's nice that TypeScript supports AMD, but you shouldn't be required to use it in order to change what gets compiled.

danoshea wrote Nov 20, 2013 at 3:16 PM

I too strongly disagree with the closure of this issue. Conditional compilation based on project configuration would be a very useful feature, and should not be hard to implement in the compiler.

Would you ask C/C++ programmers to give up their preprocessor?

Mariuszz wrote Jan 22, 2014 at 11:40 PM

I agree. It would be really helpfull if you could write
#if DEBUG  
/* code*/ 
or somehow mark function like [Conditional("DEBUG")] so all the calls to this functions will be removed in release builds

wiktork wrote Jan 23, 2014 at 11:02 AM

If you're using external modules with require.js there are two options for removing code in production builds using the require.js optimizer:

First is pragmas:
// code here
var build = 'production';
//>>includeStart("pragmaName", pragmas.pragmaName);

build = 'development';

// code there
Oh, you need those ugly semicolons sometimes or tsc will remove comments ( https://typescript.codeplex.com/workitem/2115 ).

The region inside includeStart and includeEnd will be by default available in development but removed in production builds (because flag pragmaName is not set anywhere).

See details here: https://stackoverflow.com/questions/15193767/set-unset-a-debug-flag-during-grunt-requirejs-build#answer-15207536

Second way of removing code is has.js that contrary to the name doesn't really require any libraries.

If you have code like that:
if (has("someThing")) {
    //use native someThing
} else {
    //do some workaround
Then you can set in your build configuration values for has("someThing") and they will be replaced with true or false and then optimized away by UglifyJS.

Details here: http://requirejs.org/docs/optimization.html#hasjs

BBGONE wrote Jan 31, 2014 at 9:16 AM

There was now 34 votes for the issue and it was closed.
Seems, as before the developers who develop a product are not interested in what the developers using this product think. They go in separate ways.

BBGONE wrote Jan 31, 2014 at 5:01 PM

To @rictic
How can anybody say that i vote against this feature if it does not impact your code if you dont use it?
And how can anybody say that other tools can do this, when we are discussing this tool and its usefullness?
Look at evry modern compile and you will see that this feature is a de facto standard. Even internet explorer supports conditional javascript compilation.

jraza wrote Mar 23, 2014 at 10:34 PM

Even if closed, +1 for the record

WaldemarH wrote Aug 8, 2014 at 1:54 PM

Backing up.. "Even if closed, +1 for the record"

If you need an example... I would need it when instantiating a worker:

this.m_Worker = new Worker( "Scripts/User/Page/Tabs/HeatMap/worker_heatmap.js" ); //debug...
//this.m_Worker = new Worker( "Scripts/worker_heatmap.js" ); //release...

So please don't say this is not needed... ifdef is an old and a lot of time needed feature.