fix(all): recompile when a source file is added or its output is missing

[dbrattli]

Problem

Adding a <Compile Include> through an imported .props could leave a build broken while still reporting success — Skipped compilation because all generated files are up-to-date!, exit code 0, new module never generated. The failure surfaced far from its cause (Python: TypeError: exceptions must derive from BaseException; Beam: 'Scalars' is not defined). Bad for CI: a pipeline that adds a file and reuses a warm cache green-lights a build whose new code was never compiled.

Two independent defects, both reproduced from source.

1. The project options cache ignored imported .props/.targets

Cache validity compared only .fsproj and reference timestamps. A .props adds <Compile Include> items without any .fsproj being touched, so the stale source list was reused. Adding the file directly to the .fsproj always worked.

Fixed by also invalidating on the files taking part in a project's MSBuild evaluation: transitive <Import Project>, plus Directory.Build.props/.targets and Directory.Packages.props found upwards. Only $(MSBuildThisFileDirectory) and $(MSBuildProjectDirectory) are expanded — an import path built from any other property is skipped, since missing an import costs a stale cache while guessing wrong costs a bogus path.

2. A missing output file counted as up-to-date

getFilesToCompile selects a source whose output does not exist (Main.fs:945), then areCompiledFilesUpToDate reported that same file as up-to-date (Main.fs:981) and skipped the compilation it had just asked for. No .props needed: delete any generated file and rebuild → skipped, exit 0, file still missing.

Trade-off

A file whose generated code is empty is never written, so it is indistinguishable from one that was never compiled. Projects containing such a file lose the skip-compilation shortcut — real, not hypothetical (module Empty emits no output on JS/Dart/Beam), and measured at ~1.2s recompile instead of a skip. Normal projects still skip (0.23–0.28s), so the added import walk costs nothing measurable. Losing a shortcut is recoverable; silently shipping a half-generated build is not.

Verification

Integration tests in CacheInvalidationTests.fs for both cases, checked in both directions — they fail without this change and pass with it. The deleted-output fixture has two source files on purpose: with one, the existing "no compiled files found" guard masks the bug.

Checked by hand on Python, JavaScript and Beam, which now behave identically: add via .fsproj, add via imported .props, a .props shared by two projects built in turn, remove from the compile list, deleted output regenerated.

Suites: Python 2458 passed, Integration 42 + 116 passed, fantomas clean.

Not addressed

Found alongside, out of scope here. With the two cache defects fixed, both only surface on a compile that already exits non-zero and prints the error — noisy rather than silent.

• Output files are written even when the compile fails (reproduced standalone: exit 1, a.py written anyway). This is what poisons the output tree so the next run takes the skip path. Fable compiles each file as it type-checks, and project-wide diagnostics only arrive at FSharpCompilationFinished, so gating writes on "no errors" means buffering output or restructuring that pipeline.
• The Python backend emits raise 1 — a non-exception — from F#'s error-recovery AST. A symptom of the above: generating code from an AST that failed type-checking.

🤖 Generated with Claude Code