Support conditional compilation

[mpawelski]

On codeplex this was a popular feature request:

https://typescript.codeplex.com/workitem/111
https://typescript.codeplex.com/workitem/1926

Personally I think preprocessor directives like #if, #elif, #else #endif with possibility to specify symbol to compiler would be very useful.
And a way to mark function (or ambient function declaration) as Conditional (something like ConditionalAattribute in C#) would be great improvement too.
I have lot's of console.log like function calls that decrease performance of my application and ability to easily remove all calls to this function would be great.

[RyanCavanaugh]

We'd like to gather some use cases on this. What do people want to use this for? There might be better solutions than conditional compilation depending on the application.

We would likely not implement a ConditionalAttribute-style attribute as it violates the "Don't depend on typechecking for emit" design goal.

For the console.log case, adding conditional compilation would be a large hammer for a small nail. Doing this no-op'ing at runtime would be essentially zero overhead (assuming that you would be writing a human-readable amount of stuff to the console in the debug case).

[zpdDG4gta8XKpMCd]

I can think of a few cases:

• Being able to control which parts (files) of the project are subject for a build. One can use directive constants like tags. This would allow slicing and dicing the project any way you like and focusing on certain pieces while doing refactoring. Currently in order to focus on a certain piece, say the data layer, without having to deal with cascading breaks across all layers, one has to exclude the unrelated files before and reincluding them all back after when the refactoring is done, which is a hassle. Such problem would not exist if VS had support for special TypeScript only projects that would be linked all together and could be addressed one-by-one separately.
• Enabling assertions, debugging along with all sorts of backdoors for non-production versions. While, as you say, tracing can be done without conditional compilation with debugging it is different, because it takes more granular control over the code. Also for performance critical code conditional compilation is the only option.

[NoelAbrahams]

Some use-cases:

• Variable defintion

// Production sources and keys        
   var foo = {
        root: "https://yyy.blob.core.foobar.net/",
        googlePlusKey: { id: "888888", key: "GIzdfBy" },
        facebookKey: { id: "444444444" }
     };

// Development sources and keys        
#if(DEBUG)
   var foo = {
        root: "https://xxx.blob.core.foobar.net/",
        googlePlusKey: { id: "458588", key: "BIzdfGy" },
        facebookKey: { id: "123219585123132" }
     };
#endif

• Import statement

#if(DEBUG)
       import foo = require('debug');
#else
       import foo = require('release');
#endif

function doFoo(){
    foo.someMethod();
}

• Class definition

#if(DEBUG)
       class Foo { doFoo(){ console.log('debug'); }  }
#else
       class Foo { doFoo(){ console.log('release'); }  }
#endif

var foo = new Foo();

[CyrusNajmabadi]

Having worked on the Roslyn API support for the C#/VB Preprocessor, I would def like to avoid bringing those huge complexity farms to TypeScript.

I am amenable though to other mechanism that might achieve the same goals, albeit with less flexibility.

       -- Cyrus

From: nabog [mailto:notifications@github.com]
Sent: Sunday, August 24, 2014 3:41 AM
To: Microsoft/TypeScript
Subject: Re: [TypeScript] Support conditional compilation (#449)

Some use-cases:

• Variable defintion

// Production sources and keys

var foo = {

    root: "https://yyy.blob.core.foobar.net/",

    googlePlusKey: { id: "888888", key: "GIzdfBy" },

    facebookKey: { id: "444444444" }

 };

// Development sources and keys

#if(DEBUG)

var foo = {

    root: "https://xxx.blob.core.foobar.net/",

    googlePlusKey: { id: "458588", key: "BIzdfGy" },

    facebookKey: { id: "123219585123132" }

 };

#endif

• Import statement

#if(DEBUG)

   import foo = require('debug');

#else

   import foo = require('release');

#endif

function doFoo(){

foo.someMethod();

}

• Class definition

#if(DEBUG)

   class Foo { doFoo(){ console.log('debug'); }  }

#else

   class Foo { doFoo(){ console.log('release'); }  }

#endif

var foo = new Foo();

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/449#issuecomment-53187591.

[mpawelski]

I think compiler directives would be useful in scenario when you are targeting different platforms and want to have as much shared code as possible. Similar to what compiler directives are used today in C#. Many libraries (in .net framework code too) have code with conditional compiler directives to maximize code reuse.
In JavaScript it's somewhat easier to detect if given feature is available but still there are situation when differences would be better handled by preprocessor directives for example for very different platforms (mobile, set-top-boxes, smart tv). It's sometimes easier to use compiler directive when there are differences in APIs and their behaviours.

We would likely not implement a ConditionalAttribute-style attribute as it violates the "Don't depend on typechecking for emit" design goal.

Are you afraid that sometimes it might be not clear that compiler have all type information about call (like in discussion about extension methods?
Well, for people that use noImplicitAny this won't be a problem. We are also not doing any complex code transformation. Just removing some code calls so result JavaScript code would still be readable

Conditional compilation would definitely be useful in some situation. There might be other solutions but preprocessor directives are very simple to use and might be the best (and simplest) solutions.

But I must admit that the more I think about this feature, the more I consider it less important and would understand if compiler team would focus on other higher priority features.

[RyanCavanaugh]

To be clear, "noImplicitAny" is not "noAny"

[Conditional('debug')]
declare function debugPrint(s: string);
var d = { n: debugPrint };
var x: any = d.n; // Legal even with noImplicitAny
x('hello'); // Call to 'x' will not be conditionally compiled

[mpawelski]

It looks like "full" conditional compilation with preprocessor directives is a complex thing to implement, so maybe it's not worth the effort.
But is it difficult to implement something like ConditionalAttribute so it would be easy to strip-out certain function call in code?

We would likely not implement a ConditionalAttribute-style attribute as it violates the "Don't depend on typechecking for emit" design goal.

A lot of minifiers allows to exclude console.log calls and this is often searched topic.
I understand your resistance to this feature, but I believe many will find it useful. It won't be very general and often used feature but if the costs of introducing this feature is relatively small (it might not. I just guess. I don't implement compilers.) than I think it's worth considering to add.

About syntax. I guess we don't need special syntax for attributes, something like "special comment" will be fine for me if that would be easier to implement:

/// [Conditional("debug")]
declare function debugPrint(s: string);

[s-panferov]

I have just found another one good use case for this feature. I want to to enable JSON Schema validation for API calls. And, of course, I want it only for dev and test builds.

There are two aspects of the problem:

1. I need to include modules with these schemas conditionally (I know that it can be done with async loading, but it is much more complex).
2. I need an ability to enable/disable some statements that make Schema checks.

I'm writing a lot of code in Rust language and it has a suitable solution:

• Any item can be marked with #[cfg(...)] attribute to enable or disable this item (example):

#[cfg(debug)]
mod test {
    // ...  
}

• They have the cfg! macro that can be used to disable some statements in code:

let my_directory = if cfg!(windows) {
    "windows-specific-directory"
} else {
    "unix-directory"
};

After this RFC will be done, #[cfg()] attribute will be allowed to use with any code block.

So there are good start steps for TS:

#[cfg(validate_schema)]
module schemas {
    export var schema1 = {
        // ...
    };  
}

export class UserApi extends ApiBase {
    static authenticate(login: string, password: string): Promise<{user: models.CurrentUser}> {
        var promise =  this.request('/api/auth', {
            type: 'POST',
            data: {
                login: login,
                password: password
            }
        });

        #[cfg(validate_schema)]
        promise = promise.then(validateSchema);

        return promise;
    }
}

What do you think?

[paul-reilly]

@s-panferov : it's certainly another solution, but there is potentially more code duplication than with standard pre-processor directives. I have to say that I don't understand the resistance to include them, since TypeScript can leverage the power of the compiler. It doesn't seem logical to have to jump through workarounds that scripted languages by nature need when there is an obvious and simple solution available.

[zpdDG4gta8XKpMCd]

@paul-reilly budget limit a good excuse for resistance, although I am in
your team and i say there are numerous ways to use it, although many of
them can be solved just by leveraging constants say we declare const debug = false which gives the runtime a strong hint to optimise things like if (debug) {...} up to exclusion which, at least for me, covers 90% of use
cases
On Dec 11, 2014 5:33 PM, "paul-reilly" notifications@github.com wrote:

@s-panferov https://github.com/s-panferov : it's certainly another
solution, but there is potentially more code duplication than with standard
pre-processor directives. I have to say that I don't understand the
resistance to include them, since TypeScript can leverage the power of the
compiler. It doesn't seem logical to have to jump through workarounds that
scripted languages by nature need when there is an obvious and simple
solution available.

Reply to this email directly or view it on GitHub
#449 (comment)
.

[fletchsod-developer]

How about web.config somehow? My company said it's a bad practice to use #Debug or #Release cuz it deal with processors, so my company require us to use web.config for that purpose. (The trasnformation to web.config takes care of it).

[jez9999]

I would definitely like to see conditional compilation in TypeScript. I have a use case for it right now, where I'd like to enable some JavaScript code for when developers run our application, but not include the code at all when it is deployed. Conditional compilation would be ideal for this.