-
Notifications
You must be signed in to change notification settings - Fork 453
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
TypeError: mappedCoverage.addStatement is not a function #211
Comments
This issue can be reproduced in my test repo as well, see mrijke/react-typescript-jest-demo#1 |
@mrijke thanks. Can you update the repo to use the latest versions of jest & ts-jest? |
@kulshekhar as noted in mrijke/react-typescript-jest-demo#1 (comment), I've updated to |
I don't know if this is really |
@screendriver to find that out, we'll need a minimal repo that reproduces the error you're getting :) The other linked repo isn't doing that |
I have merged the PR now that updates the versions of |
Ah ok. I didn't knew that. I thought that it does exactly that.
Great 👍 |
I tested the updated repo which reproduced this issue. The tests execute fine and it seems that the error is thrown from jest (at the stage when coverage is being generated). That said, I suspect the cause of the error might not be in jest but in the configuration (package.json and/or .babelrc). I don't use babel so I might not be the best person to comment/speculate on this. We can leave this issue open if you want to continue the discussion/collaboration here. Hopefully someone familiar with babel/jest will be able to point out a solution. |
Should I open the same issue at the Jest repo and reference this one? |
@screendriver if this error can be reproduced without using ts-jest, it might be a good idea. Without that, I'm not sure how the folks at jest will be able to help. |
Hmmm to be honest: I don't know. The new official Jest docs mention TypeScript for the new coverage feature 🤔 |
I guess might be worth a shot |
Done: jestjs/jest#3560 |
I had this issue at work last week, but being relatively new to TypeScript I assumed it was some form of configuration I'd set incorrectly. I didn't find the problem, but I traced it down to Then due to this it doesn't instantiate This is when I assumed I'd screwed up generating source maps and went back to experimenting with that, but didn't get any further before I left for the weekend. Only thing I really tried doing was using The only other bits of info I can give at the moment that may help is that I'm also pretty sure if I put in a check for |
I've had another look into this - the issue (at least with my config) is when I'm afraid this is about as far as I can take it in terms of a fix, but I hope the above info is helpful to whoever picks this up. |
Removing tsconfig.json
jest.conf.json
|
Based on the observation by @ecozoic I have a hunch of what's going on. When I'll try to check this but if someone can try this out in the meanwhile, it might lead to a quicker resolution |
To clarify, I get this error whether or not I use Repo for repro here: https://github.com/ecozoic/react-starter/tree/typescript-2 UPDATE: Deff seems to be something w/ ts-jest, I swapped out the ts-jest preprocessor for a simple one based on the official examples and I'm able to get coverage reports working (although it doesn't look like remapping is working...).
UPDATE 2: Clearing the Jest cache fixed the mapping issues. So that code snippet seems to work. |
Just for your information regarding |
This happens only when the output is piped through babel-jest. I'm not sure why it happens. I tried fixing the file extensions as suggested by @kulshekhar. |
@screendriver @ecozoic @mrijke var outputText = compilerOptions.allowSyntheticDefaultImports
? babelJest.process(tsTranspiled.outputText, path + '.js', config, transformOptions)
: tsTranspiled.outputText; with: var outputText = compilerOptions.allowSyntheticDefaultImports
? babelJest.process(tsTranspiled.outputText, path + '.js', config, null)
: tsTranspiled.outputText; to see if this resolves the issue? |
It works! But to be honest: I did an update on all of mine dependencies, deleted my |
I think it has to do with the missing |
@screendriver - I think that might be a jest cache issue - try running it with --no-cache. It works in my tests, however the coverage numbers are a little off from earlier, and I haven't had time to look into what is correct. |
I updated issue #230. I initially posted here because I thought it was the same issue, but it may not be. |
I was facing the original mapCoverage issue, as well as getting reports with the It's obviously slower generating the reports though. Can someone show a simple example of the need of babel during this process? I'm just using ts-jest for the tests, and they seem to be working well, even with async/await and Promises. I have also tried typescript-babel-jest preprocessor, and the map coverage is actually worse (it might be related to the fact that it's a really simple one). Other than that, seems to be all the same. |
@Apidcloud babel is used only when Now, if you need to use |
Hit the nail right on the head @jrwebdev - patching babel-jest to not only transpile .js files, so we could pass the correct path to it worked, both with coveragemaps and coverage. (Oddly enough, I am getting a one-off error in the #statements in coverage, but after looking at the coverage maps I think this might be more accurate) I think we should consider maintaining our own fork of babel-jest, it's a very small program and the other solution is to monkey-babel, and that seems like it'll end terribly. I doubt they'll accept a fix in their repo as this falls far outside their usecases. What do you think about that @kulshekhar |
I'm not really in favor of maintaining a fork of anything - over a period of time, they tend to diverge and cause real maintenance issues. That said, if this seems like a workable solution, maybe someone can create a separate |
I agere, however it should be mentioned that the entire of babel-jest is
approximately 60 lines.
What would the gain be in having multiple babels?
On Thu, May 25, 2017, 12:47 Kulshekhar Kabra ***@***.***> wrote:
I'm not really in favor of maintaining a fork of anything - over a period
of time, they tend to diverge and cause real maintenance issues.
That said, if this seems like a workable solution, maybe someone can
create a separate ts-babel-jest. ts-jest could then have a configuration
(for cases when babel is needed) so that the user can choose from either
the standard babel-jest or ts-babel-jest
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#211 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGFg4GacOnh6S-eIXl1mGO7sYEMfB_bwks5r9VxAgaJpZM4NY8SX>
.
--
mvh.
Gustav Wengel
|
Alternatively, we could just create a hook that can be called if provided. This would be after typescript transpilation and would supply the specified function the transpiled code as well as all the parameters that the This would be a lot more flexible. ts-jest can come with a default babel setup and those who want something different can override this hook and get the functionality they want. Edit: forgot to address this. babel-jest might be short but I don't doubt there'll be babel specific requirements that will expand our version (should there be one) to something that's completely different from the original one. We should make it easy for users to use another transformer if they want to but we should limit the scope of ts-jest to only typescript specific issues and features. |
You mean let people pipe it through babel themselves? I feel like we need to:
I feel like anything more complex than that, should not be handled by us, but by someone making a seperate transformer where they pipe the output through ts-loader and whatever else they want themselves. |
The default hook I mentioned can do this.
What are 'edge cases' to us maintaining ts-jest is really the 'main case' for users encountering them. No one but these users are best placed to address these issues. What we should focus on, imo, is making it straightforward for users to tune ts-jest to suit their needs. With that in mind, here's how I think ts-jest needs to evolve:
Apologies to all those subscribed to this issue for all the noise. We really should take this discussion over to a new issue :) |
Yes I agree - let's take it to #235 - I think we might need to resolve that before we can do real work on this issue |
I just tested this and it looks like #236 fixed it. @screendriver @mrijke can you check if this works for you |
LGTM 👍 |
Awesome! |
- Change the path of the required files in the tests to test the build files - Change the test runner to compile the typescript prior to running the tests - Change the test runner to only run the tests once (coverage also runs the tests) - Pass --no-cache to coverage to ensure it works with typescript: kulshekhar/ts-jest#211 - Stop using `grunt-ts` because it doesn't actually just pass the config through tsc. This caused problems when the new resolveJsonModule config didn't get passed through. Instead just use `tsc` to compile directly. - Modify the `tsconfig` to ensure that json files are included in the compiled package. - One line of code is no longer coverage for mysterious reasons, punt on figuring out why and just ignore it so they test continue to pass.
- Change the path of the required files in the tests to test the build files - Change the test runner to compile the typescript prior to running the tests - Change the test runner to only run the tests once (coverage also runs the tests) - Pass --no-cache to coverage to ensure it works with typescript: kulshekhar/ts-jest#211 - Stop using `grunt-ts` because it doesn't actually just pass the config through tsc. This caused problems when the new resolveJsonModule config didn't get passed through. Instead just use `tsc` to compile directly. - Modify the `tsconfig` to ensure that json files are included in the compiled package. - One line of code is no longer coverage for mysterious reasons, punt on figuring out why and just ignore it so they test continue to pass.
- Change the path of the required files in the tests to test the build files - Change the test runner to compile the typescript prior to running the tests - Change the test runner to only run the tests once (coverage also runs the tests) - Pass --no-cache to coverage to ensure it works with typescript: kulshekhar/ts-jest#211 - Stop using `grunt-ts` because it doesn't actually just pass the config through tsc. This caused problems when the new resolveJsonModule config didn't get passed through. Instead just use `tsc` to compile directly. - Modify the `tsconfig` to ensure that json files are included in the compiled package. - One line of code is no longer coverage for mysterious reasons, punt on figuring out why and just ignore it so they test continue to pass.
- Change the path of the required files in the tests to test the build files - Change the test runner to compile the typescript prior to running the tests - Change the test runner to only run the tests once (coverage also runs the tests) - Pass --no-cache to coverage to ensure it works with typescript: kulshekhar/ts-jest#211 - Stop using `grunt-ts` because it doesn't actually just pass the config through tsc. This caused problems when the new resolveJsonModule config didn't get passed through. Instead just use `tsc` to compile directly. - Modify the `tsconfig` to ensure that json files are included in the compiled package. - One line of code is no longer coverage for mysterious reasons, punt on figuring out why and just ignore it so they test continue to pass.
I updated my project to
Jest 20.0.1
and updatedts-jest
to20.0.3
as well. I tried out the new coverage feature and get following error:Coverage should run.
The text was updated successfully, but these errors were encountered: