[heft] Add support for Jest to heft.

[iclanton]

No description provided.

[octogonz]

1. For the heft-test-01 project, modify the snapshot test like this:

  it('Correctly handles snapshots', () => {
    expect({ modified: 1, b: 2, c: 3 }).toMatchSnapshot();
  });

2. Run heft test --clean. It shows:

Tests finished:
  Successes: 1
  Failures: 1
  Total: 2

3. Now run jest directly. It shows:

Test Suites: 4 failed, 3 passed, 7 total
Tests:       4 failed, 10 passed, 14 total
Snapshots:   4 failed, 1 file obsolete, 3 written, 7 total

The reason is that it is matching paths like .heft/build-cache/lib/test/ExampleTest.test.js.

To the fullest extent possible, we need the vanilla Jest CLI to behave identically as Heft's harness.

[octogonz]

we need the vanilla Jest CLI to behave identically as Heft's harness.

Let me amend this statement based on some more experimentation: The following tools all like to pretend that they are a complete toolchain:

• Webpack
• Jest
• tsc --build

But they cannot realistically reproduce the entire Heft toolchain. They will fall apart when it comes to things like:

• preprocessor tasks such as json-schema-to-typescript
• postprocessor tasks such as API Extractor and downlevel-dts
• cross-project build orchestration
• --watch mode, including Rush's upcoming cross-project watch feature

Perhaps our long-term philosophy will be like this:

• When invoked via the CLI, these tools should see config files that process their isolated inputs/outputs only
• If you run the vanilla CLIs, they should produce the same outputs that Heft would, assuming that Heft has prepared their inputs (e.g. jest will succeed only if Heft has created the .js inputs)
• Similarly, alternative hosts like the Jest VS Code extension only expected to work after Heft has prepared things; we should aim to polish this experience however possible
• Heft's features like --watch must be feature complete and expected to completely replace the vanilla CLIs
• Wherever feasible, the configs should block vanilla CLI features like jest --watch that are not going to be meaningful

Does that make sense? The alternative would be to fully integrate Heft into each of these CLIs (i.e. replacing ts-jest, ts-loader, etc) which seems unrealistically expensive in general.

This also gives us an answer for the longstanding issue of const enum not working with Webpack.

[iclanton]

This is in a generally usable state, but there are a few limitations:

• A race condition can occur between TS and Jest in --watch mode, where Jest detects that the TS file has changed before its compiled output has been written
• New test files aren't correctly picked up in --watch mode.