Closed jgranick closed 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.
I agree that the proposal is desirable. The output code would be more idiomatic and play well with various tools.
As a minor note, it may be good to provide js-es2015
as an alias: the versioning for versions after ES5 seems to prefer years rather than editions of the spec.
This proposal is so general that it's difficult to discuss. We're going to provide ES6 support and will discuss the specifics in various HaxeFoundation/haxe issues, some of which already exist.
@Simn The most pertinent feature of ES6 for us would be ES6 classes, ES6 import and (in a perfect world) different JS files per module/class.
How would you like me to propose these? Separate issues, or a more specific evolution proposal?
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