I am in the process of bumping jest from 24.6 to 26.6 and my any test that has 'jest-each' in it give the following message.
Cannot find module 'jest-each' from 'features/test_and_learn/__tests__/utils.test.js'
I've looked through the jest releases and can't find anything in particular to say that I need to use 'jest-each' differently.
Any suggestions? I can provide jest config but thought someone might know why it has happened first.
Related
My code is getting this error with using a html script using discord.js runned by electron(nodeIntergation is true and node is working in html)but I get the error: cannot find module node:events when I search it on web it says upgrade your node to 16.6 but it still don't work on 16.6
Here is the node -v command to proof
I dont't know why this is happening can someone help?
I don't know is this a good solution or gonna cause bugs but when I change some of the code in module's code it just worked(changing node:x to x just an example not real module)thanks to #Darren Cook because the thing he said in the comments make me looking to some documention on node.js and I see the modules start to calling module_name to node:module_name from some version(I guess 16.6)like I said I don't know is this a good solution but worked for me no bugs till this moment
I am working on a project under NodeJS that uses ES6 imports/exports (hence having set type: module in its package.json) and want to automate some tasks using Grunt. Now, I absolutely love grunt, but it appears to me that even in 2022 it is still not able to work nicely with ES6 modules? I always get an error saying "require() of ES Module /vagrant/Gruntfile.js from /vagrant/node_modules/grunt/lib/grunt/task.js not supported."
I understand where this is coming from, and I do understand there are workaround options - in particular, renaming Gruntfile.js to Gruntfile.cjs and passing it to grunt with the --gruntfile command line option. But that is incredibly annoying - it makes the command six times as long as it would be if I could just run grunt and be done with it. Pretty much the same goes for transpiling with something like Babel: That is exactly the kind of thing grunt is intended to handle in the first place, so it feels a bit like the horse riding the jockey. I feel like this should "just work".
Am I missing something here, or is grunt really unable to handle ES6 imports out of the box?
Actually, looking at the grunt github page it appears that a recent commit has addressed it.
I guess this issue will therefore be resolved in their next update.
The long and the short if it is thus:
Large test suite with some async/await tests (e.g. describe( async function(){const awaitSomething = something (...); expect(awaitSomething).to.equal('somethingAwaited')} or similar) that runs in node 10.15.3
Introduce a colleagues component library (which itself runs with tests in node 10.15 3)
Our large test suite fails unless we upgrade to node 12.x
Specifically this causes tests to fail even when we specify to .only run unrelated test suites. As soon as we comment out the import of the component function where it's integrated and where it's rested all other test failures cease.
We can most likely upgrade to node 12.x, but I would still like to understand what is wrong.
The only two clues are that the new component pulls whatwg-fetch, and that in node 10.15.3 we get an error (with or without the component imported) saying
ExperimentalWarning: fs.promises is experimental.
This comes from inside jsdom.
As I can't paste code from the code base, I can't make an MVP to show here, but is there a way to diagnose this? I've tried using DEBUG='*' but I can't get anything meaningful out of it. My leading guess is that polyfill is overriding something but I don't know what.
I've been hunting this one for a while, and I can't seem to find a clear answer.
Basically, it looks like when writing protractor tests (With Node 8 or higher) now everything has to be async/awaited to be able to debug the test. Is this correct?
As a test I did place await/async on one of my tests. To be able to debug, it required almost every single line to be awaited. If I missed a single line, it wouldn't debug properly. This made writing and debugging the test very janky.
Am I just missing something obvious, or is this really what I need to do?
I found the following video which seems to show this is required.
https://www.youtube.com/watch?v=6aPfHrSl0Qk&t=976s
Yes async/await is the way of the future. You can see in this question here that node 8 breaks a lot of what you're expecting to work to debug your code. To be able to keep up with the direction that Protractor is going you get to heavily alter all of your existing tests. It sucks, but I'll tell you what I've found helps.
Sounds like the first thing you need is to add the lint rule for no-floating-promises which will tell you which awaits you are missing. You can even set it to where only your e2e folder is affected by this rule, which helps if you aren't wanting to change your entire app.
Since now everything is a promise I also suggest replacing any forEach you have that involves promises. While you think that it should be sequential, it isn't. Pretty much anything and everything coming back from the browser is a promise, and if your types are outdated then some things that aren't marked as a promise will be anyhow. A for-of loop works as a decent replacement in this case. Why? The forEach will start every promise in the loop at the same time, causing WebDriver to error on you.
While you're at it, you will likely want to upgrade jasmine if you haven't already. If you're not yet on typescript 3.0 I have found that "jasmine-core": "2.99.1" along with "#types/jasmine": "2.8.9" will tell you when you are not awaiting a promise in an expect. It also does type checking in your expect, which is a plus over the older versions. These are very specific versions, the next ones up didn't seem to work with older versions of typescript.
Lastly, suggest looking at your protractor.conf and changing any beforeEach, afterEach, etc to be async and await whatever is in them.
I'm sure I've forgotten a few things, but that should get you started.
I'm trying to fix this problem for 6 hours now and I'm slowly starting to lose my mind, so please excuse my generic question.
First of all I am using:
Node: 8.10.0 | npm: 5.6.0 | Yarn: 1.5.1
I just upgraded my project to Node v8 and npm refused to install all dependencies, so i installed yarn which fixed the issue immediately.
My sources are compiled using Laravel Mix which utilises Webpack, Babel, ... internally.
Installing and compiling of my sources works perfectly fine now but for some reason my compiled js file is not working anymore (even if I downgrade to the previous Node version - 6.10.0).
Uncaught TypeError: fn.bind is not a function
at nativeBind (admin.js?id=8c4a6887899977ba8021:72515)
at initMethods (admin.js?id=8c4a6887899977ba8021:75849)
at initState (admin.js?id=8c4a6887899977ba8021:75617)
at Vue._init (admin.js?id=8c4a6887899977ba8021:76936)
at new Vue (admin.js?id=8c4a6887899977ba8021:77037)
at Object../resources/assets/js/admin.js (admin.js?id=8c4a6887899977ba8021:83350)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at Object.1 (admin.js?id=8c4a6887899977ba8021:83790)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at ./node_modules/babel-loader/lib/index.js?{"cacheDirectory":true,"presets":[["env",{"modules":false,"targets":{"browsers":["> 2%"],"uglify":true}}]],"plugins":["transform-object-rest-spread",["transform-runtime",{"polyfill":false,"helpers":false}]]}!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./resources/assets/js/components/Autocomplete.vue.Object.defineProperty.value (admin.js?id=8c4a6887899977ba8021:63)
I have aboslutely no ideas what this error means let alone what causes it.
I know that the error message is pretty generic and could probably mean a lot of things but hopefully someone knows what it means given my context.
Thanks!
#Ortomala Lokni's answer pushed me in the right direction.
For some reason I thought my problem was related to my build scripts, npm, webpack or anything of that sort, which - of course - it was not.
Event though it wasn't really an API change as he suggested there was simply a wrong call to the VueJS constructor in my JS file which, for some reason, had been ignored by a previous release of VueJs but apparently not by the current one.
For anyone experiencing some weird bugs that just don't make sense I recommend the following:
First of all: Determine what really is your problem - if it compiles it is most certainly not related to your JS build
Comment out all of your JS code in your main file
The error should be gone at this point
Narrow down the error by trying to uncomment line by line (or block by block) and test your code after each uncomment
Even though this steps might seem obvious you can easily forget about such simple thing because of the million things that could possibly break when working with modern JS.
Sometime when you upgrade libraries you have to adapt some code. As Javascript is not a typed language, the problem does't appears at compile time but at run time.
In your case, I suppose that you have a problem similar as this one.
Check which libraries yarn has upgraded and verify if some API has changed.