[RFC] Inline Snapshots #6380

azz · 2018-06-02T12:34:56Z

In the Jest 23 event recently, @cpojer mentioned that he would like to have snapshots in the source file, removing the indirection. I thought I'd have a crack at it, and it works!

It is a very simple API:

expect(x).toMatchInlineSnapshot()
expect(fn).toThrowErrorMatchingInlineSnapshot()

Snapshot updates are done with prettier for formatting, and babel for transformations, meaning if your code was already formatted with Prettier, nothing will jump around the screen, and you can use jest --watch and watch the snapshots appear before your 👀!

The code is still rough around the edges, but I wanted to get some early feedback on whether Jest wants this kind of feature.

Todo:

cpojer · 2018-06-02T12:38:04Z

This is fucking outstanding. I didn't think it would happen so soon. Amazing. I will take a look at this soon, we should absolutely make this happen and ship it with Jest.

One early nit: I think it would be better to re-use the indentation level of the expect call – what do you think?

azz · 2018-06-02T12:40:15Z

One early nit: I think it would be better to re-use the indentation level of the expect call – what do you think?

Absolutely, I was going to do that but I forgot 😄.

azz · 2018-06-02T12:43:41Z

This only took around four hours to implement, which is a massive testament to the approachability of the codebase, by the way!

SimenB

This is super awesome, thanks for working on it!

Left some inline comments, but overall this looks really good

SimenB · 2018-06-02T13:01:52Z

packages/jest-snapshot/src/State.js

    this._dirty = true;
-    this._snapshotData[key] = receivedSerialized;
+    if (isInline) {
+      const stack = new Error().stack.split(/\n/);


We can use callsites here, but it's way easier with sourcemaps to use errors.

We have an error already from the matcher on expect, but we might not pass it through?

SimenB · 2018-06-02T13:02:52Z

packages/jest-snapshot/src/index.js

@@ -72,6 +107,7 @@ const toMatchSnapshot = function(
      : currentTestName || '';

  if (typeof propertyMatchers === 'object') {
+    const propertyMatchers = propertyMatchers;


Already removed locally, I had some argument shuffling happening earlier that I didn't completely clean up.

SimenB · 2018-06-02T13:03:36Z

packages/jest-snapshot/src/index.js

@@ -102,7 +138,12 @@ const toMatchSnapshot = function(
    }
  }

-  const result = snapshotState.match(fullTestName, received);
+  const result = snapshotState.match(


Should we start passing an object?

SimenB · 2018-06-02T13:05:05Z

packages/jest-snapshot/src/utils.js

+  snapshotData: {[key: string]: InlineSnapshot},
+  sourceFilePath: Path,
+) => {
+  const sourceFile = fs.readFileSync(sourceFilePath, 'utf8');


Would be awesome to reuse the hastemap to save the fs operation.

Then we should be able to cache prettier config lookup as well

I'm unfamiliar with hastemap, got any pointers to how I would do that?

I'll have to take a look when I'm at a computer, but basically the context contains the full filesystem (and dependencies between files) in an abstraction called haste map (with haste fs in it). I'm not sure how to best access it (or if it's even possible) in jest-snapshot

orta · 2018-06-02T13:28:57Z

Honestly, this might just be good enough for me to deprecate #5718

Great work @azz

kentcdodds · 2018-06-02T13:44:05Z

Sorry for the extra notification, but I just wanted to come by and say THIS IS AMAZING!

azz · 2018-06-02T13:49:35Z

packages/jest-snapshot/src/utils.js

+          matcher.loc.start.column === frame.column - 1
+        ) {
+          if (
+            node.arguments[0] &&


Note to self: It won't always be the first argument, it should always be the last one. Property matchers should probably go first.

expect(x).toMatchInlineSnapshot( { r: expect.any(Number) }, ` Object { r: Any<Number> } `);

azz · 2018-06-02T14:43:38Z

Need to figure out how this will work with jest-each or just simple loops. Maybe switch to an array if more than one snapshot is found?

for (const i of [1, 2, 3]) {
  expect(i).toMatchInlineSnapshot([
    "1",
    "2",
    "3"
  ]);
}

Edit: Just going to fail the test for now, it's a bit fiddly to get working.

ikatyang · 2018-06-02T14:55:30Z

packages/jest-snapshot/src/utils.js

+};
+
+const createParser = snapshots => (text, parsers) => {
+  const ast = parsers.babylon(text);


How about using prettier.getFileInfo() to determine which parser to use, and throw error for parser other than babylon, flow or typescript? since we only care the astFormat to be estree here.

I tried parser: 'flow' manually when I was originally writing this, and babel-traverse threw an error, something like Couldn't find Program or Function, will need to write a bit of code to patch it, I think. cc. @existentialism

Fixed in 19c231a.

SimenB · 2018-06-02T15:39:19Z

To run with circus locally, you can do JEST_CIRCUS=1 ./jest

suchipi · 2018-06-02T18:08:29Z

Super awesome, @azz :)

azz · 2018-06-03T01:17:18Z

@SimenB Segfault in jest-circus run looks unrelated. Runs cleanly on my machine.

azz · 2018-06-03T03:24:42Z

~~TypeScript support for this might not land straight away - need to:~~

~~Figure out how to map the stack trace back to the TS source (@SimenB?)~~(apparently already works)
~~Release Support specifying parser/printer mode via name of custom parser prettier/prettier#4586~~ - Found a workaround.

SimenB · 2018-06-03T07:25:09Z

@aaronabramov thoughts on the circle segfault?

Figure out how to map the stack trace back to the TS source

If sourcemaps are set up correctly, it should just work. Have you got any examples of where it doesn't work?

azz · 2018-06-03T07:39:33Z

I haven't tested yet. How does new Error know about sourcemaps?

SimenB · 2018-06-03T07:42:13Z

We install source-map-support into the environment, and tell it to use the sourcemaps returned by transformers: https://github.com/facebook/jest/blob/3a1afceb1789d1e054de947019dfc8fe433c4576/packages/jest-runner/src/run_test.js#L118-L146

azz · 2018-06-03T10:46:10Z

It now works if you do this:

// my.test.js
test('...', () => {
  require('./other')();
});

// other.js
module.exports = () => {
  expect(value).toMatchInlineSnapshot();
};

But I just realized, since tests can be ran in parallel there's no way to ensure that the external toMatchInlineSnapshot is only called once. 🤔

aaronabramov · 2018-06-03T18:51:56Z

@SimenB hm.. it's not a segfault. apparently node process ran out of memory, which means there's a memory leak somewhere :(

aaronabramov · 2018-06-03T22:14:13Z

yeah i could reproduce it locally with JEST_CIRCUS=1 ./jest -i
is there anything we're not cleaning up? or maybe we already had a memory leak and just started attaching more stuff?

ArtemGovorov · 2018-06-03T23:35:37Z

Great feature!

@azz I may be missing something, but wouldn't it be possible to save the inline snapshot without AST manipulation in this case? Given that it seems like a straightforward replacement, couldn't just string manipulation be used (without involving babel and prettier)? It would address the following concerns:

right now the feature is only usable for Prettier enabled code bases (with no settings overrides or all overrides in prettier config). Those who are not using Prettier, or using it from various editor extensions that support loading prettier settings from sources other than prettier config, such as .editorconfig, or editor settings, will have their code reformatted. With string manipulation, the feature will seamlessly work for any code base.
with string manipulation there's no need to worry about parser, so Typescript/Flow/whatever would just work;
using string manipulation approach eliminates dependency on Babel and Prettier for the feature;
string manipulation is faster, and while not much of a concern for a single/small test file change, things can add up when updating multiple inline snapshots in multiple files.

azz · 2018-06-04T00:21:55Z

or using it from various editor extensions that support loading prettier settings from sources other than prettier config, such as .editorconfig

Config is loaded using Prettier's API, so package.json, .prettierrc, .editorconfig, etc will be respected. Notice in the GIFs that there is no bracket spacing. The only caveat is if people are using editor-specific overrides (like .vscode/settings.json) will not be picked up.

Typescript/Flow/whatever would just work

It already works 😄, Prettier supports bleeding edge proposals/features from JS, flow and TS, so we should be covered.

using string manipulation approach eliminates dependency on Babel and Prettier for the feature;

Jest already has a dependency on babel, so it's just the addition of Prettier.

string manipulation is faster, and while not much of a concern for a single/small test file change, things can add up when updating multiple inline snapshots in multiple files.

Prettier is Blazing 🔥

The main value prospect of using Prettier instead of string manipulation is probably demonstrated by the second GIF in the original post. When the string is short it will be inlined, when it is too long it will be on the next line, when there are property matchers (first arg object) everything will be in the right place. Doing that reliably with raw string manipulation would be complex and error-prone.

ArtemGovorov · 2018-06-04T01:05:57Z

The only caveat is if people are using editor-specific overrides (like .vscode/settings.json) will not be picked up.

Don't forget those who don't use Prettier, but are using Jest.

Prettier is Blazing

Sure, but (an additional) Babel parsing + Prettier code emitting is never going to be as blazing as string manipulation.

When the string is short it will be inlined, when it is too long it will be on the next line, when there are property matchers (first arg object) everything will be in the right place. Doing that reliably with raw string manipulation would be complex and error-prone.

It is handy, but can be done outside of the testing framework feature, can't it? It can be done with Prettier (outside Jest) for those who are using Prettier, and for those using other formatting tools, those tools can do it differently (the way those tools are configured to do so), and everyone would be happy.

I have nothing against Prettier as a separate tool that does its job very well. My concern is that if a testing framework feature can avoid being a specific code formatter dependent, then it probably should be.

azz · 2018-06-04T01:35:22Z

I have nothing against Prettier as a separate tool that does its job very well. My concern is that if a testing framework feature can avoid being a specific code formatter dependent, then it probably should be.

That's a fair criticism, and I'm obviously biased here. Happy to roll with what the collaborators here think the right way forward is.

ArtemGovorov · 2018-06-04T02:20:09Z

That's a fair criticism, and I'm obviously biased here. Happy to roll with what the collaborators here think the right way forward is.

I love Prettier too, also I'm a big fan of AST manipulations. What bothers me is that it can make the feature less usable/attractive for those who configure Prettier differently or are not using Prettier. If only the bit of code around the toMatchInlineSnapshot(...) was formatted, it'd be ok, but changing the whole source file formatting when updating a single inline snapshot may affect the feature adoption.

azz · 2018-06-04T02:29:09Z

I could change it to use the Range API, that way it would only format the expect() statement.

ArtemGovorov · 2018-06-04T02:33:38Z

@azz 👍 This should address the re-formatting concern. Those who are using Prettier will have their code formatted as a standalone Prettier would do, others can reformat it on the fly with their code formatters - at least it's going to be just one place to do it.

ArtemGovorov · 2018-06-04T02:39:41Z

@azz I'd still consider string manipulation though to try to not create a dependency on Prettier. I may be missing something, correct me if I'm wrong, but seems like a simple replacement.

This Pull Request renovates the package group "jest monorepo". - [jest-environment-node](https://github.com/facebook/jest) (`devDependencies`): from `23.2.0` to `23.3.0` - [jest](https://github.com/facebook/jest) (`devDependencies`): from `23.2.0` to `23.3.0` # Release Notes <details> <summary>facebook/jest</summary> ### [`v23.3.0`](https://github.com/facebook/jest/blob/master/CHANGELOG.md#2330) [Compare Source](jestjs/jest@v23.2.0...v23.3.0) ##### Features - `[jest-cli]` Allow watch plugin to be configured ([#6603](`https://github.com/facebook/jest/pull/6603`)) - `[jest-snapshot]` Introduce `toMatchInlineSnapshot` and `toThrowErrorMatchingInlineSnapshot` matchers ([#6380](`https://github.com/facebook/jest/pull/6380`)) ##### Fixes - `[jest-regex-util]` Improve handling already escaped path separators on Windows ([#6523](`https://github.com/facebook/jest/pull/6523`)) - `[jest-cli]` Fix `testNamePattern` value with interactive snapshots ([#6579](`https://github.com/facebook/jest/pull/6579`)) - `[jest-cli]` Fix enter to interrupt watch mode ([#6601](`https://github.com/facebook/jest/pull/6601`)) ##### Chore & Maintenance - `[website]` Switch domain to https://jestjs.io ([#6549](`https://github.com/facebook/jest/pull/6549`)) - `[tests]` Improve stability of `yarn test` on Windows ([#6534](`https://github.com/facebook/jest/pull/6534`)) - `[*]` Transpile object shorthand into Node 4 compatible syntax ([#6582](`https://github.com/facebook/jest/pull/6582`)) - `[*]` Update all legacy links to jestjs.io ([#6622](`https://github.com/facebook/jest/pull/6622`)) - `[docs]` Add docs for 23.1, 23.2, and 23.3 ([#6623](`https://github.com/facebook/jest/pull/6623`)) - `[website]` Only test/deploy website if relevant files are changed ([#6626](`https://github.com/facebook/jest/pull/6626`)) - `[docs]` Describe behavior of `resetModules` option when set to `false` ([#6641](`https://github.com/facebook/jest/pull/6641`)) --- </details> --- This PR has been generated by [Renovate Bot](https://renovatebot.com).

lgandecki · 2018-07-19T10:57:42Z

So amazing! I also think this: "When we render an Object, why do we not instead print the real JavaScript object right there?" would be game changing.
@cpojer if you don't have time to work on this, maybe you thought about it a bit and have some pointers how would be a good way to do it? I'd love to give it a try :)

SimenB · 2018-07-19T11:26:03Z

That's basically #4442, IDK if @orta has any thoughts on the implementation

orta · 2018-07-19T14:33:46Z

Yeah, at least me and @cpojer are on board with basically doing that @lgandecki - and I agree, doing that completely eradicates the need for #4442 IMO

The most naive implementation could be to do prettier(JSON.stringify(theObj)) to have it turn it into a real AST of the object that can be inserted.

I think what might make more sense in the long run is to have sentinels for functions which turn into expect.any`s for functions, so that they can still feel like real tests e.g:

expect(obj).toMatchSnapshot({
  myFunc: expect.any(Function),
  number: 1,
  value: {
    one: "two"
  }
})

github-actions · 2021-05-12T11:07:08Z

This pull request 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.

facebook-github-bot added the cla signed label Jun 2, 2018

azz force-pushed the jest-inline-snapshots branch from 9c04b50 to 084b4ec Compare June 2, 2018 12:35

SimenB reviewed Jun 2, 2018

View reviewed changes

azz commented Jun 2, 2018

View reviewed changes

ikatyang reviewed Jun 2, 2018

View reviewed changes

azz force-pushed the jest-inline-snapshots branch from 14d8025 to a161fe5 Compare June 3, 2018 12:08

kentcdodds mentioned this pull request Jul 2, 2018

Best ways/patterns to split app into components kentcdodds/ama#399

Closed

This was referenced Jul 3, 2018

[jest-editor-support]: jest 23.x compatibility #6586

Merged

rename prettier option to prettierPath #6607

Merged

This was referenced Jul 7, 2018

Update jest-environment-jsdom in / from 23.1.0 to 23.3.0 opencomponents/base-templates#320

Closed

Update jest in / from 23.1.0 to 23.3.0 opencomponents/base-templates#321

Merged

Update jest in / from 23.1.0 to 23.3.0 severest/retrobot#161

Closed

azu mentioned this pull request Jul 10, 2018

2018-07-10のJS: Jest 23.3.0 インラインスナップショット、npm.community jser/jser.github.io#532

Merged

azz mentioned this pull request Jul 11, 2018

Jest ignores obsolete file snapshots if there are inline snapshots #6655

Closed

sebald mentioned this pull request Jul 13, 2018

@types/jest: Add inline snapshot matchers DefinitelyTyped/DefinitelyTyped#27258

Merged

16 tasks

This was referenced Aug 1, 2018

Update jest in /modules/api from 22.4.3 to 23.4.2 project-accelerate/accelerate#207

Open

Update jest in /modules/frontend from 22.4.3 to 23.4.2 project-accelerate/accelerate#235

Open

dependencies bot mentioned this pull request Nov 1, 2018

Update jest in / from 22.1.4 to 23.6.0 leonardofaria/leozera-ui#250

Closed

SimenB mentioned this pull request Nov 10, 2018

Prettier 1.15, jsxSingleQuote and inline snapshots #7353

Closed

This was referenced Jan 28, 2019

Allow jest inline snapshots to update without affecting the whole file prettier/prettier#5807

Open

feat: make prettier optional for inline snapshots #7792

Merged

SimenB mentioned this pull request Feb 24, 2019

use typescript-eslint array-type rule #7974

Merged

francoischalifour mentioned this pull request Mar 4, 2019

test: add toWarnDev custom Jest matcher algolia/instantsearch#3574

Merged

SimenB mentioned this pull request May 14, 2019

Prettier is used by toMatchInlineSnapshot, but it is not a dependency of jest #8467

Closed

snyk-bot mentioned this pull request Mar 17, 2020

[Snyk] Upgrade expect from 23.0.0 to 23.6.0 yowainwright/react-workshop#8

Merged

github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021

[RFC] Inline Snapshots #6380

[RFC] Inline Snapshots #6380

Conversation

azz commented Jun 2, 2018 • edited Loading

expect(x).toMatchInlineSnapshot()

expect(fn).toThrowErrorMatchingInlineSnapshot()

cpojer commented Jun 2, 2018

azz commented Jun 2, 2018

azz commented Jun 2, 2018

SimenB left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SimenB Jun 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

orta commented Jun 2, 2018

kentcdodds commented Jun 2, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azz commented Jun 2, 2018 • edited Loading

Choose a reason for hiding this comment

azz Jun 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SimenB commented Jun 2, 2018 • edited Loading

suchipi commented Jun 2, 2018

azz commented Jun 3, 2018

azz commented Jun 3, 2018 • edited Loading

SimenB commented Jun 3, 2018 • edited Loading

azz commented Jun 3, 2018

SimenB commented Jun 3, 2018 • edited Loading

azz commented Jun 3, 2018

aaronabramov commented Jun 3, 2018

aaronabramov commented Jun 3, 2018

ArtemGovorov commented Jun 3, 2018 • edited Loading

azz commented Jun 4, 2018

ArtemGovorov commented Jun 4, 2018 • edited Loading

azz commented Jun 4, 2018

ArtemGovorov commented Jun 4, 2018

azz commented Jun 4, 2018

ArtemGovorov commented Jun 4, 2018

ArtemGovorov commented Jun 4, 2018 • edited Loading

lgandecki commented Jul 19, 2018

SimenB commented Jul 19, 2018

orta commented Jul 19, 2018

github-actions bot commented May 12, 2021

azz commented Jun 2, 2018 •

edited

Loading

`expect(x).toMatchInlineSnapshot()`

`expect(fn).toThrowErrorMatchingInlineSnapshot()`

SimenB Jun 2, 2018 •

edited

Loading

azz commented Jun 2, 2018 •

edited

Loading

azz Jun 2, 2018 •

edited

Loading

SimenB commented Jun 2, 2018 •

edited

Loading

azz commented Jun 3, 2018 •

edited

Loading

SimenB commented Jun 3, 2018 •

edited

Loading

SimenB commented Jun 3, 2018 •

edited

Loading

ArtemGovorov commented Jun 3, 2018 •

edited

Loading

ArtemGovorov commented Jun 4, 2018 •

edited

Loading

ArtemGovorov commented Jun 4, 2018 •

edited

Loading