[Feature]: Restore Access to Utility Functions in "jest-snapshot/utils" for Continued Tooling Support

[connectdotz]

[Feature]: Restore Access to Utility Functions in "jest-snapshot/utils" for Continued Tooling Support

[connectdotz]

@SimenB do you object we re-expose these functions/types?

[mrazauskas]

Perhaps the utils could simply be published as separate @jest/snapshot-utils package?

[connectdotz]

I'm ok with either approach. @SimenB, what's your take?

[SimenB]

Separate util package makes sense to me 👍 Happy to take a PR to that effect 🙂

[connectdotz]

@SimenB, a few follow-up questions regarding splitting the utils into its own package @jest/snapshot-utils:

Circular Reference

Is it correct to assume that you would prefer the @jest/snapshot-utils package not to depend on the @jest/snapshot package due to circular reference? If that is the case, we have the following dependency issues to resolve:

In utils.ts:

import {getSerializers} from './plugins';
import type {SnapshotData} from './types';

• The ./plugins module is not used anywhere except in utils.ts. Should we move it to @jest/snapshot-utils as well?
• The type SnapshotData from ./types is simply a Record<string, string>. Do we want to create a new package @jest/snapshot-types for a single line type definition? Or maybe the whole ./types file?

Re-evaluation

Given these issues, do we still favor splitting utils.ts into new packages (@jest/snapshot-utils, @jest/snapshot-types) over exposing it within @jest/snapshot?

[mrazauskas]

In TypeScript repo they have public and internal utilities. Perhaps similar strategy could be adopted? I mean, the new package could exposing only getSnapshotData(), testNameToKey() and other actually useful utilities not all what utils.ts contains.

By the way, I think SnapshotData can be replaced with Record<string, string>. That looks fine, because TypeScript does not have nominal types.

UPDATE: Or SnapshotData could be exported from the new package, because it is part of the return type of getSnapshotData().

[SimenB]

Moving SnapshotData to the new package should be fine, yeah

[connectdotz]

sorry for the delay, I am back to this issue now. One more question, given the jest-snapshot doesn't use the "@jest" scope (not sure what the naming rule is), do we want the new package to be @jest/snapshot-utils or jest-snapshot-utils?

[SimenB]

The old ones don't as they predate our ownership of the jest org on NPM. All new packages should use the namescaped one, but we don't wanna migrate old ones (just to avoid dependents getting left behind).

[SimenB]

https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.5