Specify a custom haxelib path or use haxe env PATH if provided

[jeremyfa]

Currently, I can manage to use a custom haxe binary and make this haxe use a different haxelib by providing it a PATH env like this:

    "haxe.executable": {
        "path": "/Path/to/some/custom/haxe",
        "env": {
            "PATH": "/Path/to/some/custom/haxe/and/haxelib/dir"
        }
    },

But this doesn't affect the get_haxelibRepo() and resolveHaxelib() methods which always use the default global haxelib.

I see 2 options to solve the problem:

• Option 1: Just like we can specify a custom haxe.executable binary path and env vars, it could be useful to have an equivalent option for haxelib binary and let vshaxe use it if provided. Like:

    "haxe.haxelibExecutable": {
        "path": "/Path/to/some/custom/haxelib",
        "env": {
            "PATH": "/Path/to/some/custom/haxe/and/haxelib/dir"
        }
    },

• Option 2: When vshaxe is calling haxelib, it could be resolved with the PATH env variable passed to haxe.executable option to ensure the resolved haxelib binary is the same between haxe and vshaxe.

If any of these two options is provided (but I have a strong preference to first option as it seems more flexible in my opinion and doesn't affect the default behaviour if not provided), it would allow to use completely self-contained per-project haxe/haxelib binaries.

Regarding the specific use case I have, it is about using haxe and haxelib installed locally on a project (through NPM), without any use of a globally installed haxe/haxelib. And it would be great if a vshaxe workspace could be configured properly for that situation!

[jeremyfa]

(btw I am open to make a pull request for option 1 if the change seems reasonable)

[Gama11]

I'm open to a solution to this, I've considered it before, but so far nobody seems to have needed it. ;)

Need to think a bit about what the best approach is.

[EricBishton]

Another approach is to not use haxelib repos at all -- don't even set it up. Pass in all of the libraries on the command line as classpaths and add the defines that the library needs. Honestly, that's the way to get full control of your compile without having individual developer's setups interfering with the process.

[jeremyfa]

The problem is that currently, vshaxe needs a valid haxelib binary to work fine, otherwise it will display some errors, regardless of your project using -lib or not.

In other words, you currently need a globally installed haxelib to make vshaxe happy.

Ideally, vshaxe should work just fine with no globally installed haxe/haxelib as long as the vscode workspace provides configuration to custom paths (and env variables) for haxe and haxelib binaries locally.

This is already possible for haxe binary with haxe.executable config but not haxelib, hence this issue 🙂

[sh-dave]

You might also take a look at lix. That gives you a project local haxe as well and works ok with vshaxe. I just set the paths to node_modules/.bin/haxe.cmd and it's working out fine so far. I haven't used it with libraries installed via haxelib though (only directly via github), but it provides a haxelibshim.js so i guess it will wrap the calls also and you don't need a globally installed haxelib.

[jeremyfa]

I am well aware of lix but this vshaxe issue about being able to configure haxelib path/env remains valid regardless.