Interactive Snapshot Update Mode outside of watch mode

[MichaReiser]

🚀 Feature Proposal

Make the interactive snapshot update mode available without requiring to use watch mode.

Add a new cli option --updateSnapshotInteractive that runs all tests and lets the user decide for each failing snapshot test whatever the snapshot should be updated.

Motivation

Jest Snapshots are an amazing feature with the main downside that users can tend to blindly update all failing snapshot tests without reviewing the changes (because it's that easy :)). This issue has been addressed by introducing interactive snapshot updates in watch mode.

Unfortunately, watch mode is considerably slower than the normal run mode resulting in long initial run times (+30minutes) when making changes to a file with many dependents (requiring a lot of tests to rerun) in a large repository (+1000 test suites). Users are, thereby, faster by updating all snapshots and reviewing the changes in the VCS diff (and reverting undesired updates). This has the downside that a user might miss an update or not reviewing the changes at all. Furthermore, reverting undesired snapshot requires manual work.

Example

jest --updateSnapshotInteractive

• Jest runs all tests
• For each failing snapshot test
  • Show the user the diff from the current snapshot to the new snapshot
  • Ask the user if the snapshot should be updated
  • Update the snapshot if the user decides to do so.

I'm not sure if Jest should first run all tests or showing the user the diffs as soon as a snapshot has failed (allows running the other tests in the background)

Pitch

Snapshots are a core functionality of Jest. The flow for updating snapshot should, thereby, be a core functionality as well. Furthermore, interactive snapshot updates are already part of jest core in watch mode.

[jeysal]

Unfortunately, watch mode is considerably slower than the normal run mode resulting in long initial run times (+30minutes)

Unrelated to your feature proposal, but this surprises me. Running tests once in watch mode should in general not be slower than running the same set of tests outside of watch mode. Is there an open issue for this performance problem or could you perhaps create a repo that reproduces this on a smaller scale?

[thymikee]

@jeysal #7341

[jeysal]

Ow, that one's bad. Unfortunately it's not magically resolved by the micromatch fix and it's going to be way harder to profile than the micromatch thing :/

[SimenB]

I like the idea of this, I'm not sure how feasible it is if you want to avoid watch mode, though. The whole interactiveness is quite tied to watch mode

[worc]

watch triggers an EMFILE: too many open files for me. so the ability to do a single run through instead of bumping up against system limits would be pretty nice.

[Rossh87]

No movement on this for a bit now, and it looks like the performance issue that prompted the initial request has been resolved by #8201. @thymikee, is there still interest in implementing this, or safe to close?

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.