You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basically the command itself does nothing more than creating a .haxelib folder at cwd.
The really interesting part is that when haxelib runs, it will search for .haxelib folder in cwd and, if it exists, use that as the haxelib path. The same applies on the haxe compiler (which uses haxelib to resolve paths I believe).
The tricky part is that the search for .haxelib only happens at cwd and will not "go up" the directory tree.
So if flow runs haxelib-related things not at project root (where my .haxelib folder resides), it will be using the global haxelib path.
You can see how I used this to check-in the haxelib dependencies of an app as submodules. So people doing a git clone --recursive will get the exact version of dependencies: https://github.com/haxe-react/haxe-react-native-sample
Because it list haxelibs from the flow script folder not the project root. So it will the global haxelib instead of the local
.haxelib
folder.flow/src/flow/project/prepare/depends.js
Line 60 in e810427
The text was updated successfully, but these errors were encountered: