As a workaround to this issue, I use fully separate Haxe installations for each project, So I’ve installed a copy of Haxe 3.4.7 for a console game I’m working on at
C:/HaxeToolkit/3.4.7_ProjectA/ and have a separate 4.0.5 installation for a PC game I’m working on at
Meanwhile, I set up my OS’s Environment Variables to switch between them, so instead of HAXEPATH being
C:\HaxeToolkit\%HAXE_VERSION%\haxe and I just change HAXE_VERSION to the subfolder name when I move between projects. It’s a bit of a hassle to set up each time I start a new project because the Haxe installer messes with it, but it’s worth it.
It helps when a project needs to be archived, too, since I can move its Haxe installation folder to that project’s location for archiving, or just leave it in place if I ever need it again.
Ultimately, it’s a bit of an odd workaround, and sorta wasteful when there’s code overlap, but it’s become a necessary workflow for me because inevitably every project I do ends up needing some dev or hacked versions of a library that other projects aren’t using, don’t need, or can’t use. And I never have to keep track of which versions of which libraries I’m using on each project.
I’ve often thought I should make a proposal to the HaxeFoundation folks to support something like this officially, at least to the point where you can more easily have multiple Haxe versions on one machine, a la Unity Hub or the AIR SDK.