Proposal: Preprocessor Directives #4691
Comments
|
I, personally, don't like the idea of adding a preprocessor to TS. But a preprocessor like this will never be in ECMAscript, and it follows no ECMAscript patterns or semantics - so there's no real hope that support for it would broaden in the JS community in the future. While preprocessor directives give great flexibility and power, there's no runtime JS equivalent for them - you're just using TS as a... well... JS preprocessor. The most common argument I've seen an argument for why people "need" a preprocessor is when they refuse to do dependency injection for dependencies which change with compilation target (test primitives, etc) - using them as a shortcut, a hack, for avoiding refactoring their code - so maybe I'm just a bit bitter at all the bad code I've seen. @mhegazy mentions here that TS would be more likely to take a |
|
Historically we have been very resistant to preprocessor directives, especially control flow type directives (in contrast to a more declarative thing like #Deprecated). That said, it's clear that we do need to investigate better ways for people to make the compiler aware of which subset of their runtime environment they're targettng at design time. |
|
Since this proposal is really aimed just at supporting more granular @weswigham would a I agree that preprocessor directives have very weak appeal in a JavaScript environment, which has adequate alternatives. However with regard to conditional inclusion of core types to match real-world mixed ES5/6/7 targets (like in #4692), there are no alternative language-level mechanisms. The only other way is to split the core typings into many small files and work out which ones to pass to the compiler, which is just conditional compilation by another means. |
With some dead code elimination, yes. If you enable babel's dead code elimination alongside decorators it... kinda does the right thing right now. (Some bits get too aggressively culled while others aren't pruned as much as they could. Both features are experimental, so I'm not expecting perfection.) For example, you can do this with babel right now: var debug = true;
function LogSetter(descriptor) {
if (debug) {
if (descriptor.set) {
let oldSet = descriptor.set;
descriptor.set = function() { console.log(...arguments); oldSet.call(this, arguments); }
}
}
}
class Foo {
@LogSetter
set name(value) {
this._name = value;
}
}
(new Foo()).name = "yes";When function LogSetter(descriptor) {
if (descriptor.set) {
(function () {
var oldSet = descriptor.set;
descriptor.set = function () {
console.log.apply(console, arguments);oldSet.call(this, arguments);
};
})();
}
}and function LogSetter(descriptor) {}With a little bit more intelligence/fixup it could know to omit the decorator entirely. But anyways, what I'm getting at is that using normal JS constants to control your runtime changes and some good dead code elimination with actual JS conditions can cover "conditional compilation" most if not all of the time. And the best part about it is that you can disable dead code elimination and inspect what options caused what branch eliminations at runtime, making it much easier to debug than a tangle of |
Right, however the problem scenario presented in this proposal (selectively choosing parts of |
|
@weswigham to add to my above comment, as long as other solutions can be found to 'selectively choosing parts of lib.d.ts files', that don't require adding a proprocessor to tsc, I agree that preprocessor directives are unlikely to have other compelling use cases. The other scenarios all seem to have adequate alternatives either at runtime or as you mention through things like dead code elimination. |
|
@weswigham the purpose of dead code elimination is to optimize code bases by eliminating dead code. Debug code for me isn't dead. Dead code for me is an unused public method in a library. And the trick you describe is being branded as an ugly hack, people began to use the method you described along with different minifiers a long time ago. Dead code elimination has no directives. So when programmers see that code, how do they know it will be eliminated? I think programmers wants a distinct syntax to handle preprocessing. I still think preprocessor directives makes a lot of sense. JS has the most widest platform usage of all programming languages, and when we programmers now program code using compilers instead of vanilla JS. I think a feature like preprocessor directives makes a lot of sense to target different platforms. This feature will never likely be implemented in JS so it fits TS also. |
|
D did this very well without preprocessor directives, using what they called 'static if'. It has roughly the same semantics as 'if', but can be used in type definitions, and is evaluated at compile-time. It cannot slice through arbitrary text, like preprocessor macros can. |
|
Some languages can accomplish that with hygienic macros. I'm not sure we'd want hygienic macros, though. |
|
That's true. I was thinking something simpler than most hygienic macros are. // ambient
interface App {
quit();
if (false) {
eraseHardDrive();
}
if (Platform === "OS X") {
setApplicationMenu(menu: Menu);
getApplicationMenu(): Menu;
}
if (Version >= 3) {
magicVersion3Function();
}
}(In this case, Platform and Version are identifiers whose values are known at compile-time, through hand-wavy magic.) I don't have an exact proposal in mind - my hope in bringing this up is more that if this feature does make it in some form, it can be done leveraging the syntax and concepts already present in TypeScript. |
|
@rhencke reading that, I'm vaguely reminded of Dlang's static conditions (http://dlang.org/version.html). Could have something like: interface App {
quit();
static if (false) {
eraseHardDrive();
}
version(OS_X) {
setApplicationMenu(menu: Menu);
getApplicationMenu(): Menu;
}
version(3) {
magicVersion3Function();
}
} |
|
@RichiCoder1 Not a coincidence. ;) See: #4691 (comment) |
|
I need to learn how to scroll apparently haha. |
mhegazy
added
Suggestion
|
I have a suggestion for this. I think we can accomplish this without introducing new syntax into the language. We can do this through conventions plus compiler options. Let's say the convention for a conditional compilation symbol is like: const ALLCAPS. So with the following code: const DEBUG = false;
if (!DEBUG) {
console.log("release");
} else {
console.log("debug");
}It is compiled normally by default keeping both condition blocks in the emit. Now if we compile with a special compiler option like var DEBUG = true;
if (!DEBUG) {
// removed
} else {
console.log("debug");
}That would be the simplest form, but we could even optimize it further to totally remove the {
console.log("debug");
}Notice the curly braces and therefore the scope of the block is preserved. For the negative condition the compiler option would be |
|
@omidkrad |
|
I'm not in favor of supporting |
|
I am in favor of support |
|
@gregoryagu introducing |
Another scenario that could potentially benefit from this which is not covered by the above are |
|
Another thought occurred to me: this could also be extremely useful for solving some of the issues in #4337. The "wrappings" around definitions ( |
|
I agree, this would be a useful feature. It would also be useful if they could be set at an 'environment' level, so for example the |
|
I strongly oppose this in ts files preprocessor directives makes the file much harder to statically understand which would be bad for tools as well as programmers. It's also a sign of bad code and can the need can always be solved by a refactoring. |
|
I have a need for this also, since I have code that is only necessary in a dev/test environment and not in production. It would be great if I could write something like this: |
|
I am missing multiple things with the TypeScript. These things would really help in the TypeScript code development. And I am pretty sure I am not alone. a) References in Visual Studio. They are useless in the TS project now. I would welcome it would work as in C# project where I can reference other "Lib" projects in the same solution or external libs. b) Preprocessor. It does not need to be included in the compiler itself. Moreover, it would be better to have it separate as a first stage of the build process. On other hand, it should understand the code so isn't it better to have it directly in the compiler? c) Namespace / Module / Library merger. Everything what is in the same namespace / module / library should be merged to a single file before compilation. What the hell is reason to need of exporting the class in the same namespace in order to be possible to refer it in another file but the same namespace? Also, the result code for splitted namespaces / modules is not ideal. If I will have 100 classes in the same namespace but splitted to 100 files, the result code will contain 100 closures representing this namespace. d) Minifier. I am not talking about just removing whitespaces. I am talking about something what google closure compiler is doing when advanced options are switched on. Before the TS is compiled it should be possible to minify it. At least for the production builds. Additionally, I would welcome the minifier is able to recognize string references to object properties and minifies also these strings. I would say this can be done using some annotations (not decorators as somebody recommended) or the preprocessor directives. e) The transpilation should be the same as it is now, but it would be necessary to do one addtitional step after compilation. Refresh map files to match the original code before preprocessing, merging and minification. This would not require any changes to ES, runtime support, neither to the TS transpiler itself. Everything would be still the same as before, except some additional features how to control the build process and look of the final JS output. |
|
Would love this. I have a project that doesn't use modules and now I reuse parts of the code for a project using modules. I would use an export statement at the end of my file like this: |
|
👍 |
|
As developer with C++/C# experience would be happy to see this feature in TS. |
|
How about -- instead of having to come up with new syntax -- just simply recognizing compiler directives embedded in comments, similar to the Web Essentials region directive? //#if DEBUG
console.log("debug mode");
//#endifThis should be absolutely trivial to implement on top of existing compilation logic, as no additional syntax is required, only simple comment parsing. |
|
as a proof of concept, I've written a webpack loader (ifdef-loader) that does conditional compilation with the syntax of compiler directives in As a bonus, it works for normal JavaScript files too, not only TypeScript. That BTW raises the following problem: imagine to have a typescript library supporting a conditional compile (e.g.: |
|
The function is useful, and I think there are two ways to resolve this:
The first one method is elegant and thorough. The second method simplifies problem, and could resolve the second point in #10490 by plugin self, but could not cover all scenarios. |
|
I think doing this in comments, perhaps triple-slash ones to differentiate from normal comments is the best option. You don't need to add any special non-ECMA syntax, yet can still benefit from the feature. /// #if DEBUG
console.log("hello!");
/// #endif |
|
@niieani got your suggestion and turned to triple slashes in ifdef-loader. My first impression from using in production is that directives in comments are rather dangerous... Also, it's not always possible to write clean code that validates in the IDE, often the directives do conflict (e.g. declaring two vars, etc..). |
|
@nippur72 indeed, good points. I guess TypeScript would have to support this natively so that IDE can understand all the different possibilities. Not so easy. |
|
I'm really hoping for this (or something similiar) to be added to TypeScript. Currently we're using a self-built precompiler in our company that strips away parts of the code based on set precompiler flags. Unfortunately this results in a lot of error messages in IDEs that support TypeScript but not our precompiler syntax. By now we have quite the extensive in-house library that we house client and server applications. The part of the code that is shared between the client and server is about 95% of all code. Most of the time it is small methods and variables that have to work / be set differently on the server and the client side. Using precompiler flags for conditional compiling helps us to prevent a large amount of (unnecessary) code duplication. |
|
I stopped using a preprocessor (the above mentioned ifdef-loader) in favor of simple if(DEBUG) {
console.log("this won't be included in production!");
}Of course not everything is wrappable around an class SomeClass {
someMethod() {
if(DEBUG) {
console.log("this won't be included in production!");
}
}
} |
|
@nippur72 , that's a nice idea, but unfortunately it will produce a lot of compiler errors if you have modules, libraries and classes that aren't shared across client- and server-side. A (simplified) example: |
RyanCavanaugh
added
Too Complex
|
Points on this:
Overall, there are scenarios (statement-level ifdefs, etc) that are already well-supported by existing tools, and other scenarios (parse-time ifdefs that could fundamentally mess with the AST) that we really don't want to support due to wanting to avoid a C preprocessor nightmare. There are some new opportunities to inject phases into the emit pipeline and people can try those out if they want to try to take existing JS patterns of |
|
Just to note...
Yes, but its the same as if you say there are plenty minifiers or whatever other tools. Nothing can do better than compiler itself. Same as with minification.
No. It does not. If I have references in the file I am lost. So conditional compilation sucks here. See #15417
Agree. A lot of work with doubtful results. |
Honestly, I wouldn't really consider this as a valid use-case of precompiler directives. For this task, dependency injection could be much better instead, with a clever outsourcing of the non-common parts (we do this on web/desktop/mobile builds using a similar common core code-base). This is only my opinion of course, but still, I wouldn't rely on precompilers here. |
I'm not quite sure I understand your approach. Doesn't this just move the problem from the actual class to the service class? I'd still need some way to load and instantiate a different service class depending on the target environment. |
No, the whole point of dependency injection here would be that you inject a different "service class" instance into the core of your application, depending on whether you build for server or client (with your common code-base not knowing and not caring about the actual service implementation, as long as it has the required interface). Your app core would only define the required methods (and any properties) in the form of interfaces, and it would be then up to a platform-specific implementation to actually ship these interface implementations. For example, we are building an application for web, Electron, and PhoneGap, and we are shipping a single app core to all 3 platforms. However, all 3 platforms require completely separate logic for opening, reading, writing, and saving files (e.g. we use the Node.js FileSystem API on Electron, and a virtual filesystem on web). The application core does not care how this file handling logic is done, we simply inject an implementation for file handling and that's it. This does not require precompilation, as the application core is imported into the platform specific wrapper project. |
TypeScript does not have preprocessor macros. It was proposed in microsoft/TypeScript#4691 but never added to the language.
and others
This proposal is based on a working implementation at:
https://github.com/yortus/TypeScript/tree/preprocessor-directives
Problem Scenario
Whilst the TypeScript compiler has some options to control what to emit for a particular source file, it currently has limited support for controlling what is scanned into the compiler from a particular source file. A source file is either included in its entirety, or not at all.
This makes some scenarios difficult. For instance, there are two default lib files,
lib.d.ts, andlib.es6.d.ts. A program may be compiled against one, or the other, or neither. If only some ES6 typings are desired, then either they must all be taken (usinglib.es6.d.ts), or a custom set of core typings must be maintained with the project.Even if the core lib files were further subdivided into smaller modular files that could be selectively included in a build, problems would remain. For instance, consider an ES6 built-in,
WeakMap, which has members that use the ES6Symbolspec and the ES6Iterablespec. How many files must theWeakMapdefinition be broken into to keep the lib files feature-modular?Related scenarios have been discussed in other issues:
This proposal focuses on the
lib.d.tsmodularity problem, since that was the core requirement for the related proposal (#4692) that motivated the working implementation.Workarounds
With regards to compiling core typings for only some ES6 features, some workarounds are:
--target ES5and selectively add ES6 typings in separately maintained files (eg from DefinitelyTyped).--target ES6and be careful to avoid referencing unsupported ES6 features (the compiler won't issue any errors).--noLiband manually maintain custom core typings in your own project.For other scenarios, such as supporting
DEBUGbuilds orIOSbuilds etc, a common practice is to use a single codebase with conditional execution to differentiate behaviour in different environments. This generally works well, except if conditionalrequire(...)s are needed, as these can be a problem for some module systems that statically analyse module dependencies.Proposed Solution
This proposal adds a new kind of syntax for preprocessor directives.
Preprocessor Directive Syntax
A preprocesor directive:
#if,#endifValid:
Invalid:
Directives with Arguments
A preprocessor directive may take an argument. If so, the argument appears after the directive identifier on the same line. The directive identifier and its argument must be separated by at least one whitespace character.
Under this proposal, only
#iftakes an argument, which must be an identifier. An extended proposal may expand argument syntax to include preprocessor symbol expressions.Contextual Interpretation
If a syntactically valid preprocessor directive appears inside a multiline comment or a multiline string, it is not considered a preprocessor directive. It remains a normal part of the enclosing comment or string.
Preprocessor Symbols
A preprocessor symbol is an identifier used with some directives (only
#ifunder this proposal). Preprocessor symbols have no values, they are simply defined or undefined. Under this proposal, the only way to define a preprocessor symbol is using thedefinecompiler option (see below).Preprocessor symbols are in a completely separate space to all other identifiers in source code; they may have the same names as source code identifiers, but they never clash with them.
#ifand#endifThe
#ifand#endifpreprocessor directives signal the start and end of a block of conditionally compiled source code.#ifmust be given a preprocessor symbol as an argument.#endiftakes no argument. Each#ifin a file must have a matching#endifon a subsequent line in that file.When the TypeScript compiler encounters an
#ifdirective, it evaluates its preprocessor symbol against a list of defined symbols. If the symbol is defined, then the TypeScript scanner continues scanning the source file normally, as if the directive was not present. If the symbol is not defined, then the compiler skips all the source code down to the matching#endifwithout compiling it.#if...#endifblocks may be nested. Inner blocks will be unconditionally skipped if their outer block is being skipped.The
defineCompiler OptionPreprocessor symbols may be defined at compile time using the
definecompiler option, which takes a comma-separated list of identifiers.Possible Extensions
This proposal is limited to a small set of features that are useful on their own, but may be expanded.
In particular,
#ifand#endifalone are sufficient to address thelib.d.tsproblem described above, as evidenced in the working implementation of #4692. The ability to nest#if...#endifblocks effectively allows logical ANDing of preprocesor symbols.Possible extensions include:
#defineand#undefdirectives to add/remove preprocessor symbols from within source code. However the question of symbol scope then arises.!(logical NOT),&&logical AND, and||logical OR.Backward Compatibility, Design Impact, Performance, etc
Remaining Work and Questions
The working implementation implements preprocessor directives in the TypeScript scanner, since they are really a filter on incoming tokens. This works fairly well for this limited proposal, but questions arise if extensions were added:
#define/#undefwere added, how should preprocessor symbols be scoped? Global? Per file? The scanner has very limited control over scoping. Hence currently preprocessor symbols are all globally scoped and provided using a compiler option (or internally generated by the compiler).The text was updated successfully, but these errors were encountered: