-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Fix issue with jest caching of block.json files #16899
Conversation
…ith the block json file
module.exports = { | ||
...babelJestTransformer, | ||
getCacheKey( src, filename, ...args ) { | ||
const isBlockIndex = /block-library[\/\\]src[\/\\].+[\/\\]index\.js/.test( filename ); |
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.
I don't think it's very useful as part of @wordpress/jest-preset-default
in the current form. The issue is that this check is very specific to the structure of the Gutenberg repository and it will never match with any block definition which is maintained by other projects.
Moving forward, I see 2 ways of handling it. We either move this override to https://github.com/WordPress/gutenberg/blob/master/test/unit/jest.config.js which is local to Gutenberg or we find a way to approach it for all projects which load block.json
. Given that we want to rework how block.json
is loaded as proposed in #16088, it might be better to apply this transform to local unit tests config.
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.
Thanks for the feedback. Yep, you're right, it shouldn't be in that package. I've moved it to the appropriate place. It still seems to work.
041213e
to
076d1d5
Compare
// src together. This will result in the cache key changing and the cache being | ||
// invalidated for the index when any changes to the json are made. | ||
const blockJSONSrc = fs.readFileSync( blockJSONFilename ); | ||
return babelJestTransformer.getCacheKey( `${ src }\n${ blockJSONSrc }`, filename, ...args ); |
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.
Interesting, but it fully aligns with what Babel does as far as I can tell :)
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 is great, thanks for working on it @talldan 👍
I haven't tested myself so your call whether you want me to do it :)
Thanks! I'll merge. After all, it'll only affect tests and if we see issues it can be reverted easily enough. |
* Generate cache key for block index files by concatenating the index with the block json file * Move implementation to the test/unit folder
* Generate cache key for block index files by concatenating the index with the block json file * Move implementation to the test/unit folder
Fixes #16176
Related #16150
Short description
This PR fixes the way jest caches block.json contents by ensuring the cache is invalidated when the block.json file changes.
Long description
Block.json files are built by inlining the json as a JavaScript primitive into the index.js file they're imported into using
babel-plugin-inline-json-import
.This seems to have caused an issue with jest's caching system. When jest builds a cache, it does so by generating a unique key for each file. Json files don't seem to be included in this cache. When a block.json is changed, jest seems to just look at the block's index.js source, and generates the same cache key because it hasn't changed. This means that often when adding new attributes to a block, the test results can be inaccurate because the built index.js still contains the old version of the block.json.
This PR fixes the issue by ensuring that jest generates a cache key for the block index.js that incorporates the contents of the block.json too.
How has this been tested?
npm run test-unit test/integration/full-content/full-content.spec.js
npm run test-unit test/integration/full-content/full-content.spec.js
Expected Result (what happens on this branch)
The tests for the paragraph block should fail
Actual Result (what happens on master)
The tests still pass because the attributes from the block.json are still cached.
Screenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: