Now I’ll create a symlink of /opt/haxe to whichever version of Haxe I want to be the globally installed one. And I’ll symlink the haxe and haxelib binaries to /usr/bin to make them available to all users (typically just me):

Now, Haxe can sometimes auto-detect the following, but I find it’s safest to just specify it. I often put these in my ~/.bashrc, though they could/should go in /etc/profile.d/haxe.sh to truly be part of the “system-wide install”:

But note that I can, for one (shell) session or one script, override the system install by placing the other version on the front of my PATH (which then overrides the binaries in /usr/bin), and overriding HAXE_STD_PATH.

Excellent. Now the haxe4 alias invokes haxe 4, even if haxe 3.4.7 is my system-wide haxe. So I can type:

> haxe -version
3.4.7
> haxe4 -version
4.0.0-rc.1+1fdd3d5

Some will argue that a system-wide installation of Haxe is bad / singleton-esque. Meh – I want “the typical” version installed and always ready. If a project needs a specific version of Haxe, I’ll either switch my shell (shown above), or setup some docker CI scripts and a .travis.yml for that project (using all the commands you just learned above!)

If you learn about environment variables, symlinks, and docker, you’ll have an extremely powerful set of tools in your belt!

A fresh command line shell will default to Haxe 3.4.7, because that’s what is installed through a .deb package as system default. So for Haxe 3 I don’t have to do anything.
If I want to switch to Haxe 4 I simply source that script e.g. with . haxe4.env (or source haxe4.env) and now that shell is a Haxe 4 shell, everything launched from there will use Haxe 4 (I typically use shells to launch everything, even VSCode).

It seems the problem Lix had with vshaxe’s eval-debugger extension has been fixed (seemed to be an eval-debugger issue). I’ll keep using Lix for now, but I appreciate knowing exactly how the alternatives work now, in case I need to fallback in the future.

I used to just install all Haxe versions using official installer and configure HaxeDevelop to store the Haxe version. This works good enough if you’re the only dev and keep using Windows.

For me it didn’t work when I wanted to use Haxe in automatic deploys etc (on Linux), or when a developer on Mac wanted to contribute to my project. Also my haxelib dependencies were a mess. That’s when I decided to switch to something that works across different OS-es and is easy to install for anyone. So now I use lix too.

I don’t install lix globally, but always per project (global installation kinda messes up installations), so it’s always added as local dependency. It’s great when you do * lots * of projects like me and want have haxe/haxelib versions locked (so it still works after years without figuring out which git version you used at the time)

Lix is super nice; switch Haxe versions just by changing it in the .haxerc file.

Getting started with lix is as simple (assuming you have node installed):

As much as I appreciate knowing how people have their homebrew solutions to switching Haxe versions and isolating haxelibs per project, now that the recent quirks with vshaxe have been fixed, I’d really recommend Lix to anyone reading this topic.

It’s analog to conveniently bundling (no pun intended) bundler + rbenv (if you’re used to the Ruby eco-system) in a single tool with a good CLI interface that provides a very good UX.

Being able to quickly install haxelibs from git hassle-free up to the specific commit hash I need is one of the features I love about Lix. It’s very easy to build a snapshot of haxelibs + haxe compiler version without the need to bundle everything in the repo.