try to throw at the end to avoid unreachable code

yeah, did that, and just goes back to same behavior as before

Eslint disable the line https://stackoverflow.com/a/27732264 The console thing is literally just the console being cleared before the test is run. We can pair on it at some point. It’s likely worth documenting in detail. Debugging across iframes can be weird.

We should just get on the phone at some point. I’m interested to understand what’s up.

Somehow, your e2e support file is not loading properly, probably because of the webpack preprocessor

That’s really the only difference.

I’ve never really seen that webpack error in e2e now that I think about it. It generally only throws directly to console

True. I can do a call no problem. Might just have to walk me through things a little extra at times

Like maybe you’re running CT somehow.

can you try removing the preprocessor from the plugins file?

Is running multiple instances of Cypress generally discouraged?

Yes

It’s untested

The server is a bit of a singleton so I’m not sure what would happen

I guess I'm testing it often, haha

Lol

I know it isn't possible to run multiple chrome instances spawned by cypress at once, which pretty much means the new CT runner can't be used with multiple instances. I just mean the electron part I guess. But I work on multiple projects at once, so keeping multiple open is convenient.

and this is when the runner just fails earlier, because it can't interpret a lot of things earlier on. All related to what we went through on Wednesday and why I split the plugins file. Or do I misunderstand what you mean I should do?

Just to be on the same page, I think fhe file:preprocessor is mostly useful for compiling stuff imported in support/index.js and others

ok, so, I think I'm mostly wrong. Maybe it was again due to using webpack for CT but not really needing it for E2E, but only having one plugins file. So having two may have resolved that and I was mistaken that we still needed a preprocessor for e2e. I removed it and it all seems fine. But in the case where someone did want a preprocessor with E2E, I wonder if this issue would arise...

I do not see the issue in this screenshot?

There is none, the library is working when I took out file:preprocessor

IE: Just have this for plugins for e2e

So this was a long way to arrive at a very simple conclusion, indeed. Sorry my noobness is showing... If it helps, I think this approach of configuring CT and e2e to have different support files is more pertinent when introducing CT testing. So maybe having that documented more clearly might help for future users. Looking back, I think it is one thing that really made things feel more difficult to a coworker of mine, when he first setup Cypress. Though he is even more new to Cypress. I've been focusing on CT for so long and not E2E that I didn't really notice this issue over all that time.

Yes. It really would be. Would you be comfortable drafting up a md file against cypress-documentation?

It doesn’t need to be perfect and we’ll clean it up if you submit a PR

Don’t worry about any organization. You can just append into the component-testing/introduction.md ^.^

I'm trying to upgrade to v7. We are currently using cy.request to fetch some information from a local api to use as input to our tests. v7 seems to break something. I'm not seeing exactly how we are supposed to migrate away from that pattern. It seems like intercept is not appropriate here? halp? more info: it looks like previously we were able to

await

the result of a cy.request().as('alias') and now we cannot? update: ok yes it looks like

await

is no longer allowed, but wrapping it in a Cypress.Promise works. Is this a regression or planned?

I think I can do that. I've never contributed to the documentation, so it might take me a while. Do I fork the main repo and find the right file, or is it a more specific repo?

@User @User Ok apparently it was on my side I didnt import my css good 😒 Thanks a lot for your reactivity i will definitely give a try to it now 🙂