-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add resolver for custom snapshots paths #6143
Conversation
CI is failing, mind looking into that test? |
Yes, will do. Haven't managed to reproduce with neither |
|
||
if (typeof custom.resolveSnapshotPath !== 'function') { | ||
throw new TypeError( | ||
'snapshotResolver does not have a resolveSnapshotPath function', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about:
Custom snapshot resolver must implement a `resolveSnapshotPath` function.
Documentation: https://facebook.github.io/jest/docs/en/configuration.html#snapshotResolver
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@viddo What if, instead of picking a resolver to the snapshots, the resolver resolves the |
@sidferreira, I'm not sure what you refer to by Either way, I'm reluctant to expose more internals than necessary, as it makes it harder to change those in the future as they practically then becomes a "public API" and affects the semver. Also, while I don't mind changing the implementation, the core team have the final say so I leave it to them to answer this. |
Finally managed to get my hands on a Windows computer so I could reproduce and fix the failing tests. Any more feedback or thoughts on this? |
Codecov Report
@@ Coverage Diff @@
## master #6143 +/- ##
==========================================
- Coverage 66.97% 63.45% -3.52%
==========================================
Files 250 236 -14
Lines 10355 9137 -1218
Branches 3 3
==========================================
- Hits 6935 5798 -1137
+ Misses 3419 3338 -81
Partials 1 1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs an entry on the changelog
Left some test nits
|
||
const snapshotDir = path.resolve( | ||
__dirname, | ||
path.join('..', 'snapshot-resolver', '__snapshots__'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
path.resolve
normalizes, so just path.resolve(__dirname, '../snapshot-resolver/__snapshots__');
should be enough
|
||
const fileExists = filePath => { | ||
try { | ||
return fs.statSync(filePath).isFile(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fs.existsSync
is not deprecated, please use it (async is deprecated)
|
||
describe('Custom snapshot resolver', () => { | ||
const cleanup = () => { | ||
[snapshotFile].forEach(file => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should just drop the array here
|
||
// $FlowFixMe dynamic require | ||
const content = require(snapshotFile); | ||
expect(content['snapshots are written to custom location 1']).not.toBe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expect(content['snapshots are written to custom location 1']).toBeDefined()
@@ -0,0 +1,100 @@ | |||
'use strict'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
genereal comment, path.resolve
normalizes, so you don't need to comma separate the varargs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 better now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…realized I only fixed it on the other files, also updated this one now.
|
||
function mustImplement(functionName: string) { | ||
return ( | ||
`Custom snapshot resolver must implement a \`${functionName}\` function.\n\n` + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should the heading be bold?
Also, please rebase to ensure the snapshots are correct. I have a feeling some trailing newlines are gone, so it would fail when merged to master |
Will do, thanks for the additional review! |
Good call ✅
Gotcha. Rebased but didn't see any trouble, but probably better safe than sorry. :) |
8fe886f
to
49d2e7a
Compare
Friendly bump; I believe I've addressed all the code review comments that's been brought up so far, what's expected to be changed/done for this PR to be accepted at this point? re: the changelog, it keeps getting conflicts due to other updates, so I'll fix that as a last task. |
We are targeting web, ios, and android with a single code base. Having this feature will allow us to share more code between the different platforms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs a rebase, but code LGTM
Nice job, thanks for sticking with us! |
@viddo thanks for the great work, it is very useful indeed!!! and @SimenB for the reviews an merging. I'm using it and works very well except for one little detail. Both testPath and snapshotFilePath args are absolute paths. I think it would be desirable they be relative to the CWD. In the meantime, this is a hack what works around the issue. module.exports = {
// resolves from test to snapshot path
resolveSnapshotPath: (testPath, snapshotExtension) =>
'__snapshots__/' + /src\/(.*)/.exec(testPath)[1] + snapshotExtension,
// resolves from snapshot to test path
resolveTestPath: (snapshotFilePath, snapshotExtension) =>
('src/' + /__snapshots__\/(.*)/.exec(snapshotFilePath)[1]).slice(0, -snapshotExtension.length),
// Example test path, used for preflight concistency check of the implementation above
testPathForConsistencyCheck: 'src/components/example.test.js',
}; |
It might make sense to pass in |
I think there isn't any use case where you will need absolute paths so users will always end up transforming to relative. The absolute path of any file will always differ between different computers, so for the same test file you will end up having a different snapshot per user. |
If you need to read the file or something. IDK, but it's easier to say "here is the file" and let people do whatever they want with the path rather than making it relative. If we make it relative, what should we make it relative to? |
I may be wrong but I can only imagine "src" folder. But I believe that is the more common use case and should be the default. Your idea about passing in a config is great but should be for the other cases. Does that makes sense? |
Jest for instance does not use |
- Input component, with supporting Hint, Label and ErrorMessage components. - Use template tests from `govuk-frontend` via `govuk-frontend-template-spec` Note: At the moment, Jest snapshots are manually copied across. When Jest 0.24 comes out there will be a feature to allow the snapshot test location to be configured (jestjs/jest#6143), so will keep the manual process for now, with the aim to load them in from node_modules when 0.24 is out.
@SimenB if you have a quick minute, could you confirm for me the version this was released in? I can't find any mention of I'm trying to get as much info as I can for the typings :) Also, do you know if its possible to use a Please let me know if there's value in me making an issue on the |
24.0.0
Easiest is to search for the pr number in the changelog. It's also mentioned in the release blog post: https://jestjs.io/blog/2019/01/25/jest-24-refreshing-polished-typescript-friendly#other-highlights
I don't know, I've never used this option. I don't see why it shouldn't work though |
Thanks a bunch! No idea how I missed that 😂
Thats what I thought, but Jest complains:
It works fine if I convert it to
I also tried putting in |
Oh sorry, I misread the question as resolving to ts files, not using ts in a resolver. That probably doesn't work, but we can (probably) make it work. Mind opening up a feature request? |
Just what I wanted to hear ;) I've made #8330 for this. |
@viddo I know it's been a while, but is there any chance you could provide the setup that you use to get this to work with Bazel? Might be helpful to document this in the rules_nodejs repository example for jest integration. |
@CaerusKaru you're probably looking for https://github.com/formatjs/formatjs/blob/main/tools/jest.bzl#L46-L66 most things work out of the box including snapshot update |
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. |
Summary
Provides a solution to #1650, by adding a configuration option to define a custom module that can resolve test<->snapshot paths. This enables people to decide where the snapshot files gets written on disk.
The implementation was based on this suggestion: #1650 (comment)
I left the code to still assume
.snap
extension on the snapshot files however, since I wasn't convinced how useful it would be to override that too. Could be fairly easily solved by consolidating theEXTENSION
usages.Motivation
My primary motivation for this PR stems from constraints by the Bazel build system, as also explained on a comment on Add support for --preserve-symlinks:
The sandbox is discarded after the test run, so any written files that are wanted afterwards must be written elsewhere (special directories also provided by Bazel, as it doesn't allow to write wherever you want outside the sandbox).
Judging by the reactions there are probably also other use-cases and rationales that motivates this feature.
Test plan
Existing tests covers the default resolver behavior well. I've added some new unit and integration tests to cover the configurable part.
I could add some more test cases of course, but wanted to get some initial feedback before spending more time on this.