Thank you for posting detailed reproduce steps, that's very helpful.

I can reproduce. It also happens with gopherjs build or gopherjs run too, not just gopherjs serve.

Deleting impl.a from GOPATH/pkg/darwin_js/alltom/impl.a makes it produce correct compile error:

$ gopherjs run main.go 
impl/impl.go:8:9: cannot use FooImpl(0) (constant 0 of type FooImpl) as alltom/iface.Foo value in return statement: missing method Bar2

Since there's a compilation error, that impl.a doesn't get created. But if it already exists from a previous successful compilation run, it gets incorrectly used despite being stale.

It appears the problem is something like this. When a built archive file is stale, GopherJS correctly tries to rebuild it. However, if that package fails to build due to errors, it problematically still goes ahead and uses the stale file.

This is a bug in the build logic.

I'm not completely sure this diagnosis is correct. While investigating #568, I added some debugging output to build.go, and I found that the caching/building logic appears to be working.

On a per-package basis, the cache is correctly used. Using my example in #568, for instance, after my change to bar.go, the bar package is re-built. However, the compile error is never detected, because foo is not rebuilt--because it hasn't changed.

So it seems that because 'foo' was valid at the time it was created, there is no compilation error, and the cached object is used. And because bar is valid now, there is no compilation error. The error is the failure to validate that foo and bar still link together properly. I don't know where that check belongs. My compiler/linking theory is weak-to-non-existent.

For our reference, there may be additional information in the duplicate issue #568.

#598 (comment) is related too.

So it seems that because 'foo' was valid at the time it was created, there is no compilation error, and the cached object is used. And because bar is valid now, there is no compilation error. The error is the failure to validate that foo and bar still link together properly. I don't know where that check belongs. My compiler/linking theory is weak-to-non-existent.

Here's what I think should happen. I'll use original example from this bug report, since I was able to reproduce it earlier.

Say you have iface and impl that compile initially, and main uses both.

In reality, impl imports iface, and main imports impl.

As soon as you "edit iface.go to change Bar() int to Bar2() int", that should make archive file for impl stale, because a dependency has been modified more recently than the archive file was built.

So, when compiling main, which imports impl, impl should be rebuilt, and an error should occur then.

I haven't looked at your example yet, I just wanted to think this through with the one I tried earlier.

I suppose it's also possible for impl not to import iface, but for main to import both impl and iface. But in that case the build error should happen when rebuilding main.