"Cannot read property '0' of undefined" using NX Workspace and Automatic Configuration #2758
Labels
Comments
|
I ended up adding the following to my Now instead of immediately giving me the error, it takes 10 minutes of work. _Originally posted by @kevinbeal in #1101 |
|
@kevinbeal - Could you please provide us with your Wallaby Diagnostics report. Wallaby Diagnostics Report is a simple JSON text report that contains some basic information about your Wallaby config and project that is required to start troubleshooting most of Wallaby issues. To share the report:
|
|
Thanks for taking the case! Here's my report. |
|
We couldn't reproduce your problem but believe we have found and fixed a fault in Wallaby that was causing your issue. Could you please update to the latest version of Wallaby core, Wallaby should update automatically for you, but if it does not, you may force a core update. Also, if your project is opensource/publicly available, would you mind sharing the link with us as we may be able to run it ourselves to see the problem first hand. |
|
It's still happening. Diagnostic incoming... |
|
The diagnostic report appears to be missing the error, and the error disappeared form the wallaby console seemingly on it's own without changes to my open files. Here's the diagnostic report anyway, in case it helps. |
|
Could you please try manually deleting Jest's cache directory. The folder to remove is: |
|
I will if it comes up again. It only came back up once and went away without any file changes, if I recall. This is a dramatic improvement from before. I'm satisfied, personally. |
|
Unfortunately we are experiencing the same problem, even with the latest core (1.0.1128). My colleagues and I are currently using a trial version of Wallaby. When it works it's really great, but this constantly crashing is a showstopper. So hopefully this can be quickly fixed? Thanks in advance! |
|
@JohanHeyvaert Can you please try the following:
|
|
Thanks for your response. |
|
@JohanHeyvaert - are you using VS Code? You may also try running the |
|
Since I've cleared the jest cache yesterday the problem didn't reoccur. Fingers crossed! If it happens again I'll try with WebStorm via Reset Wallaby Cache. Does this something else than the manual cleanup of jest? |
|
The problem just reoccured, so I tried the Reset Wallaby Cache feature. Unfortunately this seems to uninstall Wallaby?! Both the wallaby app and core were removed from WebStorm. Since my company's security settings block the automatic installation I have to reinstall it manually. I don't know how to reproduce the issue, Wallaby seems to crash randomly after I change source code or tests. |
This sounds like a bug. It's a recently added feature and should only remove your Wallaby cached projects folder. We're investigating this now.
Wallaby has its own cache for file that have been modified after it started that may/may not yet be committed to disk; this is what we asked you to clear. Jest also maintains its own cache of transformed files. I suspect that the issue is in this mechanism (not necessarily the fault of Jest). RE: "Cannot read property '0' of undefined" Can you also please provide us with your Wallaby Diagnostics report as it may contain additional information relevant for us diagnosing your problem: To share the report:
|
|
Can I send you the report privately? The file counts almost 5500 lines. Also I'd rather not share customer's data in public (even if there's no sensitive info in the file). |
|
Also, with the reinstall yesterday I have yet again a new version of Wallaby (core v1.0.1130). I'll let you know if/when it crashes again. Until now that error did not yet occur, but yesterday it seemed like the tests were continuously running in a loop. I had enough of it so I stopped Wallaby and have only restarted it today. |
Yes, please send it to hello@wallabyjs.com. |
|
I don't know if this is related to this problem, but I notice that Wallaby sometimes is relaunching all (or a lot of) tests when it's really not needed. Sometimes it seems that the tests are running non-stop? |
|
@JohanHeyvaert - thanks for providing the diagnostics report via email. Have you had the problem since yesterday? Could you please:
This may be related but may also be caused by the code changes that you are making (depending on what you're changing and if your changes generated any global runtime errors). |
|
Okay, the problem reoccured, while I was updating some code. The tests were running while I was writing (which happens a lot of course if you use the automatic mode) and it crashed. I don't know if the crash is caused by invalid code. I'll send you the diagnostics and console output. (done) |
|
I saw that today there's a new version of the WebStorm plugin. I haven't installed it yet. Do you think it may help to avoid this problem? |
|
The new version of the WebStorm plugin is to fix this:
Going to take a look at diagnostics report now. It's getting late here (10PM) so may not be able to provide an update until tomorrow. |
|
No worries, take your time! Maybe I could get a new extended trial license though? I was not really able to enjoy 100% of what Wallaby should have to offer. ;-) |
|
No problem, we'll send you another trial license. The issue is not related to your editor, looks like it's something specific to your project/configuration. It's very unusual but I am sure we will be able to sort it out. For some reason, it seems that Wallaby and Jest cache are not synchronised correctly. Wallaby contains self-correcting core to fix this scenario but it seems that is also not executing. We really appreciate your patience as we work through the issue. |
|
So far I've been unable to reproduce your problem, but we have a suspicion as to the cause, which may also explain:
From your log, the I'm wondering if for some reason a type error is leading TypeScript to not output the code for a file or to else output it incorrectly which then results in Wallaby cache misaligning with Jest cache. Am I right in assuming that when running from the command line, your tests will fail on a TypeScript type error? Ideally, you should configure Wallaby to not error on TypeScript type errors (i.e. make sure I'd like to try updating your TypeScript configuration when Wallaby is running (it may require creating a different Please also read our recent blog post on optimizing typescript as it explains a few things about what's going on when using TypeScript and may provide some alternatives to using If the type checking leads to global errors OR ripples through other files as they're run, then this may also be a cause of:
Could you please try change the TypeScript configuration as suggested. If you can switch to use something other than We'll do some further testing early next week to try and reproduce the problem now that we can see when it occurs. |
|
Thanks for your suggestions. This morning, I have:
I'll clean the cache and retry once more. I would like to try compilation with Babel or swc, but I don't really have the time to investigate how to do that. |
|
We've just released an update to Wallaby, |
|
Thanks, I'll give it a spin. |
|
Until now the problem didn't return. Seems stable now. There is one other problem I noticed: in the report app the coverage % is sometimes negative. |
That's great news. Since you're running in offline mode, it's worth mentioning that we made some additional enhancements (again) to try fix up when Jest cache becomes bad. We usually release features, bug fixes, updates to latest version of technologies that we support, etc. multiple times a week so it's probably worth manually upgrading periodically (at least).
We have seen this ourselves from time to time but haven't been able to reliably reproduce the issue. Feel free to create a new issue. If you're able to reliably reproduce it, we'd appreciate any instructions you can provide. |
|
I get it all the time now since upgrading my NX workspace. I tried deleting the cache with 3 separate methods which did nothing. There was some guidance about resetting cache at the node module level via a Wallaby config option, but I don't know how to determine which module would be the culprit and I do really like the automatic configuration so would prefer not to introduce a wallaby config file (but will obviously if there's no other choice). I sent in the diagnostic report to hello@ |
|
Thanks for the diagnostics report. We can see why there's an error. A bit of background for you first to explain the issue. When Wallaby runs on your project, it modifies your code in a non-breaking way to report live value displays, code coverage indicators, etc. For code that is transformed (e.g. TypeScript, JSX, etc.) these modifications happen after your code has been compiled. The error that you're receiving indicates that the number of regions in your code is not the same when running the same code file between different projects in your mono-repo. This means in some cases, one project is generating more lines of code / functions in the transformed file than another project. When Wallaby tries to identify the regions in your code at runtime, the mismatch is causing it to fail. We can see that the transforms between your projects are different, which explains your issue. Expecting transforms for a given file to be the same across different projects is currently a key assumption we've made while developing Wallaby and I'm not sure if we're going to be able to address your issue. You should be able to fix the problem by making sure that your jest transforms are the same across all projects for various file types. I can understand how this may not work for you though. We're going to investigate if we can fix this within Wallaby but it may be a limitation that you will need to workaround, either by changing your transforms or by limiting which projects in your mono-repo are run together when using Wallaby (i.e. with a custom configuration that only runs projects where the transforms are the same). We should get back to you in the next day or so with either a solution or to let you know that you'll need to change your transforms or use a custom Wallaby configuration. |
|
Thanks for the response Simon! I just changed the transforms that used Do they need to be configured identically with all the same options? I know I used to have different transform options previously without this issue. I'm very willing to change my transforms, but I don't know how to do it in the right way. |
They need to generate the same number of operations in code for Wallaby to instrument. If the configuration is identical, the same code should be emitted. If they are not configured identically with all the same options, the code output by the transforms will almost certainly be different. We're working on an update for you so that Wallaby won't crash when this occurs, but it's possible that error messages and code coverage won't be reported correctly. We expect the update to be completed in the next day and will update this issue when it's available. |
|
I was able to get rid of the error by removing Vite from my NX Workspace in favor of Webpack. It caused several other problems and so are glad to be rid of it. Win-win, really. The hint about common configurations led us there, so thank you. Thanks for all the support. We're happy to recommend wallaby. |
|
Glad to hear that you were able to align the transformations across the shared files of your project. I think this is the best way to fix the problem when you're able to. For the future, for those not able to align transformations for shared code, we have updated Wallaby to better handle this scenario from Wallaby core |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm constantly running into this with automatic configuration. It never starts with the error. It comes in when I make any change.
What are the defaults for
filesandtestswhen using automatic configuration? If I knew, maybe I could find any offending files. I tried adding this to my package.json to override them, but it didn't run any of my tests at all.I'm using jest with an NX workspace, if that matters.
Originally posted by @kevinbeal in #1101 (comment)
The text was updated successfully, but these errors were encountered: