Fred Emmott

> Just to clarify: you're proposing that most files should output something, so we can check the output? Yes, or at least it should clearly be an intentional decision to...

> Couldn't we put all these things in one file? For example a json file of sorts? Pretty strongly against this: - being compatible with the way Hack/HHVM internal tests...

> the_file.php This could/should be extracted by the build system from code blocks in the markdown: - would improve developer experience - when an example needs updating because of a...

That said, at some point, we probably do want to end up with .php/.hack files on disk: the test run is *much* faster now that all the 'no errors' files...

The no.auto.output files are unrelated to testing - they merely prevent the markdown processor from including the output in the produced documentation. Their presence should be entirely independent of *expect*

- how do .expectf and .expectre fit in? - you'll probably get pushback here: this requires making the HHVM test runner consider '.no.auto.output' a valid expect file, and that doesn't...

alternatives: - kill .no.auto.output completely - flip the default: Require a marker file on the rare occasions that embedded output is actually wanted - always put output in an html5...

> Oh OK if we need to preserve compatibility with that, we could do something like: We only use a custom thing for typechecker tests - we use run.php for...

> (we can also flip the default, foo.auto.output.hack vs foo.hack, I'll check which is more common) FWIW this was originally the other way around, and most are still from there...

We definitely need to document the 'essential' ones (like allowed_fixmes_*), though fwiw, I recommend keeping your .hhconfig as empty as possible; it's the most-tested configuration. With the HSL being built-in,...