Within @swc-node/jest, you're caching the previous transformation result, which is something that jest does internally already. We have a relatively large code base with 17,000 tests and we were finding that memory usage was quite high. Upon looking at the heap usage, we found that the same transformation strings were in memory multiple times.
Jest already caches transformations. You provide a getCacheKey function to handle changes in config. I noticed that @swc/jest has the same issue, but someone has created a PR that adds the getCacheKey function see - #32. Removing the cache from this lib and adding getCacheKey reduces the memory usage significantly and subsequently reduced the total time by 10seconds for us.
If you also return a createTransformer function, you get the config for transformations directly, and do not have to handle the differences between jest 26 and 27. The PR above also uses that. It can pretty much be changed to this:
Within @swc-node/jest, you're caching the previous transformation result, which is something that jest does internally already. We have a relatively large code base with 17,000 tests and we were finding that memory usage was quite high. Upon looking at the heap usage, we found that the same transformation strings were in memory multiple times.
Jest already caches transformations. You provide a getCacheKey function to handle changes in config. I noticed that @swc/jest has the same issue, but someone has created a PR that adds the getCacheKey function see - #32. Removing the cache from this lib and adding getCacheKey reduces the memory usage significantly and subsequently reduced the total time by 10seconds for us.
If you also return a createTransformer function, you get the config for transformations directly, and do not have to handle the differences between jest 26 and 27. The PR above also uses that. It can pretty much be changed to this: