Personally, I like making the root of a haxelib the same as the root of my repository. It makes it simple to “git clone” then “haxelib dev openfl openfl”, etc, rather than “haxelib dev munit munit/src” and other things that can be confusing to someone who is not familiar with the structure.
Haxelib adds the root as a classpath by default. You’ll see how this leads to /openfl/display/Sprite.hx (etc) in the repositories. Haxe will ignore classpaths that are either mismatched with the “package” at the top of the tile, or that start with “_” in the folder name, so if you use “tests/mytest/Main.hx” that will be hidden from code-completion.
A little “trick” though, is that FlashDevelop does not ignore subdirectory paths (in older releases, might be fixed in dev) unless there is a “haxelib.xml” (left over from the older Haxelib 1 format), so that’s why Lime and OpenFL have dummy “haxelib.xml” files, to improve completion and hide our test, sample, etc directories.
If you’re interested, OpenFL supports “include.xml” files within haxelib directories, which enables the ability to add some project tags, including (Lime and OpenFL both define this) a tag for specifying a directory path for use with “openfl create”, so you could do “openfl create flump TestProject” or whatever, if you’re interested