EricBishton
commented
6 years ago While this proposal adds a new 'define' (or compiler conditional variable definition) to the compiler, it changes the semantics of the current '-js <filename>' parameter. This will cause some difficulties for IDEs and other tools that currently manage the compiler parameters and expect output given the current semantics. Additionally, a define can be created in many places within the system, beyond the command line, and tools may not have access to them -- or will have to be significantly changed to have such access. (For example, a define can be created in '--macro' arguments, in actual macros in the source code, in project files, or via the haxelib.json and extraparams.json in libraries. Since appearances in code can also occur inside of compiler conditional blocks [behind another define] that places a further barrier to knowing whether the define is enabled.) Not only that, but this would place the meaning of the output flag within the realm of libraries, under which, many, if not most, users prefer not to modify.
Instead, since the output semantics of es6 generation change, I would propose a new target ('--es <dirname>' or '--jsmodules <dirname>'?), rather than a conditional variable.
To be clear: This is not a comment upon the desirability or relevance of this proposal -- only the proposed mechanism of achieving it.
demurgos
Simn
jgranick
ES6 is obviously the future of JavaScript, and is supported by all major browsers. Modern client-side development is designed for modular ES6 output, and macro-based solutions are clumsy.
Let's take our JavaScript to the next generation