Haxe

ok, i put a trace at the top of the function and a little further down, and only saw a single trace... which is interesting

reminder: there's a macro debugger in vscode 😉

```haxe
        var fullClass = fileParts.concat([className]).join(".");
        if (ComponentClassMap.hasClass(fullClass) == true) {
            trace("here");
            return fullClass;
        }
```

so... something to do with the ComponentClassMap already having data

so i guess i could clear it everytime the macro runs...

isn't it good if it's already populated and thus has to do less work on subsequent compilations?

well, it seems it doesnt have the actual class though

so it looks like first time round it builds the dynamic class and puts a class name in the class map

the second time round its already in the class map, so it doesnt build it... but... its not actually there

not sure if relevant here, but something to be aware of is that static variables are reset between compilations unless they're @:persistent

none of this explains why it would already fail during the first compilation though

```haxe
    macro public static function processModules() {
        if (_modulesProcessed == true) {
            return macro null;
        }

        ComponentClassMap.clear();
        
```

are you sure you're not connecting to a vscode server that's already been running with your "command line compilation"?

i.e. did you actually start the haxe server yourself?

im not using command line now... im pretty sure i was connecting to the vscode instance before

well, then it wasn't the first compilation

was the second as you said, first was the cache

then command line was just connecting to that

but adding that .clear() means i can compile just fine

but i wonder, is it the right thing to be doing?

doesnt hurt, but should i be looking for a deeper issue somewhere?

ie, why does the class map have info that the build doesnt actually seem to have