-
-
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
PROCESS function of babel-jest returns the code-map object when config.mapCoverage is set to true #5257
Comments
There's no reason to not always return the map, is there? This diff should be enough: diff --git i/packages/babel-jest/src/index.js w/packages/babel-jest/src/index.js
index 4dd71bac..82a40013 100644
--- i/packages/babel-jest/src/index.js
+++ w/packages/babel-jest/src/index.js
@@ -70,7 +70,7 @@ const createTransformer = (options: any) => {
plugins: (options && options.plugins) || [],
presets: ((options && options.presets) || []).concat([jestPreset]),
retainLines: true,
- sourceMaps: 'inline',
+ sourceMaps: true,
});
delete options.cacheDirectory;
delete options.filename;
@@ -129,7 +129,7 @@ const createTransformer = (options: any) => {
// babel v7 might return null in the case when the file has been ignored.
const transformResult = babelTransform(src, theseOptions);
- return transformResult ? transformResult.code : src;
+ return transformResult || src;
},
};
};
EDIT: It probably would be a breaking change, so use |
As this would be a breaking change, there doesn't seem to be a lot of upside to doing this - from a practical perspective. On the other hand, it (transformers returning a map) looks like a cleaner alternative. It also creates a structure for transformers to provide additional information in future should Jest decide to add features that would depend on transformers returning certain info. One minor source of confusion could be related to how this would affect inline sourcemaps. Would they continue to be processed as they are now or will Jest require transformers to return sourcemaps separately? |
Upside is performance - looking through the source code with a regexp for an inline sourcemap, then parsing it, is heavier than just receiving it. The producer also does not have to encode the sourcemap into the source file, saving even more time. It would be a breaking change for other users of
Yes, good point. Maybe some way to opt out of coverage, for instance (#5209).
Inline sourcemaps is the fallback. The way it works now is that if a |
I meant the upside in introducing the breaking change by requiring transformers to return a map. I'm not disputing the performance benefit in returning a map. If a transformer is actively maintained and updates to returning a map, it gets the performance boost. However, if a transformer is not actively maintained, this change would render it unusable with newer Jest versions. To be fair, the number of transformers is probably small enough to not care about this. But I don't know this for certain so I thought it'd be better to bring this up. |
I didn't mean that transformers must return an object with This part of the code would remain unchanged: |
Option will be removed in the next major version of Jest |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Do you want to request a feature or report a bug?
request a feature
What is the current behavior?
return result.code
What is the expected behavior?
as mentioned in mapcoverage, expected return an object like this
The text was updated successfully, but these errors were encountered: