Rebuild not triggered when deletion with nested modules

[rickyvetter]

It seems in some cases when working with nested modules there can be some correctness issue with the build. Here's a minimal repro I've found:

// Test_A.res
let foo = 1

// Test_B.res
module A = Test_A

// Test_C.res
let bar = Test_B.A.foo

Expecting a compile error after deleting Test_B.res.

[bobzhang]

I can reproduce it, it seems that Test_B is only a bunch of module aliases that we treat it specially.
Edit: So Test_B is indeed removed, it is that the build system believes that Test_B is a namespace file, hence Test_C treat it specially. @rickyvetter can you confirm that in your real world cases that Test_B is just a list of module aliases?

[rickyvetter]

Yup. There are some additional module type statements, but it's basically just module aliases.

I can also repro the same thing with a single include at top level, but that's a rarer case and I know include causes issues anyway.

[bobzhang]

Taking a closer look.
test_c.d indeed changed,
so we can either fix in the generator level
or in the ninja level.
Note this was an intentional tradeoff to avoid too much recompilation when file deletion/addition happens, but I think we can get a more robust fix now.
Edit: so we are going to fix this in ninja, if the contents of dynamic dependencies changed it is gonna trigger a rebuild.

[bobzhang]

fixed in this commit rescript-lang/ninja@61651e2