[purs ide] Updates the cache-db.json file on rebuilds

[kritzcreek]

This patch makes it so we update the content hashes when rebuilds through the IDE occur. We've still got some unfortunate invalidation going on when recompiling a file with no changes, but at least this way the IDE can never cause purs compile to invalidate too little.

One non-local change is that we now do some path normalisation for the cache-db entries, so two invocations like purs compile "src/*.purs" and purs compile "./src/*.purs" don't cause the compiler to invalidate every module.

I plan to do the file watcher replacement in a follow-up PR.

[hdgarrood]

I just want to check again that I've understood the issues you're solving here properly, does the following sound correct?

• firstly, we don't normalise file paths in the cache db, which means that we end up with IDE rebuilds invalidating everything below the rebuilt module even if there are no changes, because e.g. "./path/to/module.purs" is considered different to "path/to/module.purs", and if you're building things both with purs compile directly and with the ide you can easily end up with a mixture
• secondly, we don't update the cache-db.json file at all when the ide rebuilds a particular module, which means that the source file's timestamp has changed on disk but the cache db still contains the old timestamp, which causes the cache to be invalidated for that file, causing it and everything below it to be rebuilt on the next full build, even when there are no changes

Is that it, or is there more to it than this?

[kritzcreek]

firstly, we don't normalise file paths in the cache db, which means that we end up with IDE rebuilds invalidating everything below the rebuilt module even if there are no changes, because e.g. "./path/to/module.purs" is considered different to "path/to/module.purs", and if you're building things both with purs compile directly and with the ide you can easily end up with a mixture

Yes, in addition to that mixing absolute with relative filepaths has the same effect.

secondly, we don't update the cache-db.json file at all when the ide rebuilds a particular module, which means that the source file's timestamp has changed on disk but the cache db still contains the old timestamp, which causes the cache to be invalidated for that file, causing it and everything below it to be rebuilt on the next full build, even when there are no changes

That's the harmless case. With the current situation you can imagine the following sequence:

1. The user makes an edit without saving
2. The IDE rebuilds against a temp file and writes out a changed externs file
3. The user discards the unchanged save without triggering a rebuild
4. The output/ directory now contains an externs file that does not correspond to the .purs file on disc, but can't be invalidated by a normal purs compile because the cache says the timestamps and content hashes match

[hdgarrood]

Ah yes, thanks for reminding me.

[hdgarrood]

Looks great, thanks!

[kritzcreek]

Thanks for taking a look!

[wclr]

@kritzcreek

• The user makes an edit without saving
• The IDE rebuilds against a temp file and writes out a changed externs file

Why should IDE write out a changed a externs file if it doesn't produce the codegen output (codegeTargets is empty)? It seems that if no output is produced and externs/cache-db is not touched this couldn't break anything for later purs compile. And this would allow having absolutely pure diagnostics for non-saved files in the editors.