Refactor build to use an hxml file

[elsassph]

Currently the build process parses the hxml file and generates arguments list for haxe compilation - this is verbose, doesn't scale well, and has subtle edge case issues (like --macro with quotes in them, see #28).

Is it possible to use the hxml file as is? It doesn't seem to be possible because we need to replace the JS output target and only a single -js is allowed - maybe using a macro could work? A macro could dynamically replace the output file without touching the hxml

Otherwise we could generate a temporary hxml file It should include the original hxml content with just the JS output replaced. Other added arguments should still be added to the build command.

[jasononeil]

If we use a temporary file, and utilise an NPM like https://www.npmjs.com/package/tmp, we will need to take care to handle any relative paths. It might be easier to create a temporary hxml file in the same directory, and just be careful to clean it up.

If the macro option works that would probably be cleanest though.

[aliokan]

I have missed something, or --each and --next will do the job, about the multiple -js? https://haxe.org/manual/compiler-usage-hxml.html

[elsassph]

@aliokan no, the loader supports only a single JS output, and we need to replace the output target to generate a the file in a temporary location. In a single output, having -js several times (once in the hxml and once as an override) isn't allowed - this is a shame.

[kevinresol]

Why it is needed to replace the -js path?

Is it possible that haxe-loader parses the input hxml and figure out and use the output path from there?

If the -js tag is from a included hxml, the webpack output would be basically empty, e.g.:

haxe build.hxml

build.hxml:

-cp src
path.hxml
-lib xx

path.hxml:

-js out.js

[elsassph]

@kevinresol the problem is that the HXML is usually also used for IDE autocomplete as-is, hence why it will usually have a -js otherwise Haxe completion doesn't work. It's very convenient to troubleshoot the build outside Webpack as well. But otherwise we want to completely hide the output.

@jasononeil for HXML the paths are relative to the working directory, not the HXML location, so we wouldn't even have to fix the paths (remember they become literally compiler arguments).