Integration tests that ensure dependencies are recompiled or not recompiled depending on mtime

[ry]

It's not clear to me that we correctly recompile dependencies when some file deep in the dep tree is changed. I think the only way for this to work correct is if the dependency tree is written into the cache... But maybe I'm wrong.

We need to verify this is correct before 1.0

[bartlomieju]

Related issue #1692?

[bartlomieju]

Informational note: currently TS files are recompiled if their' hash doesn't match hash of compiled version.

File hash is calculated using this function:

pub fn source_code_version_hash(
  source_code: &[u8],
  version: &str,
  config_hash: &[u8],
) -> String {
  gen_hash(vec![source_code, version.as_bytes(), config_hash])
}

So hash consists of compiled file contents, Deno version and content of tsconfig.json (if it's provided). That means that touch some/ts/file.ts won't trigger recompilation. The other problem with this approach appears when you consider two separate Deno processes:

$ deno -c tsconfig.json some/ts/file.ts &
$ deno some/ts/file.ts &

This might not work as expected because two different processes will compile the same file and put it's compiled counterpart in cache, however they use different compiler configs which might cause strange quirks. Some time ago we talked about "lock files" for DENO_DIR, but nothing concrete was settled upon.

[hayd]

I wonder if a solution to this may also present a solution to #200 (an "integrity" hash on the dep tree to match against).

[bartlomieju]

No longer relevant after recent refactors to TS compiler and module graph (#7225)