:sparkles: feat: MetaMask setup in Cypress

[matstyler]

Motivation and context

Install MetaMask in Cypress.

Does it fix any issue?

https://linear.app/synpress/issue/SYN-124/setup-metamask-extension-for-cypress

Other useful info

Quality checklist

• [x] I have performed a self-review of my code.
• [x] If it is a core feature, I have added thorough e2e tests.

⚠️👆 Delete any section you see irrelevant before submitting the pull request 👆⚠️

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
synpress	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 18, 2024 9:42am

[Seroxdesign]

Few things to note here:

Since we are doing some cacheless setup from what I can tell in your PR, and we're doing the same thing for Playwright in my current WIP PR. It might make sense to create a shared folder of functions for cypress/playwright.

Also have you run into any problems trying to run things using Cache in Cypress?

[Seroxdesign]

You forgot to git ignore the download directory

[Seroxdesign]

1. Unit tests are failing
2. Does this include using cache for Cypress? Here is a potential setup to make this happen
3. I'm concerned we're going to have a difficult time with merging and dealing with conflicts given we've been developing in silos for the last month.

I've created a dev branch for v4 beta, I would appreciate if you could merge into there as we prep for V4 beta release, since we've been working on structural changes, leaving prs open for weeks, and dealing with conflicts can get very time consuming.

https://github.com/Synthetixio/synpress/pull/1175

[matstyler]

1. Unit tests are failing
2. Does this include using cache for Cypress? Here is a potential setup to make this happen
3. I'm concerned we're going to have a difficult time with merging and dealing with conflicts given we've been developing in silos for the last month.

I've created a dev branch for v4 beta, I would appreciate if you could merge into there as we prep for V4 beta release, since we've been working on structural changes, leaving prs open for weeks, and dealing with conflicts can get very time consuming.

1175

1. Yes, I pushed a few fixes today.
2. No cache. It will be a separated task to cover that.

How is it better to use different branch? There will be the same conflicts here and there right?

[Seroxdesign]

How is it better to use different branch? There will be the same conflicts here and there right?

The reason I am pushing for us using the new-dawn-dev branch is so that we don't have to hold off on merging our work together, for example:

1. Right now we can't merge to new-dawn without thorough reviews, which is causing us to work in separate fragmented PRs, only dealing and updating PRs as ones make it through review
2. When we make big structural changes we need to update/deploy our packages to npm, however some changes need to be done using workspace:* since our repo has many interdependencies and as far as I know only @drptbl can update npm
3. it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.
4. It will allow us to organize the v4 BETA release under 1 branch and do a thorough test prior to launch.

I know it's a bit of a pace change but I'd really appreciate if we can adopt this.

[matstyler]

How is it better to use different branch? There will be the same conflicts here and there right?

The reason I am pushing for us using the new-dawn-dev branch is so that we don't have to hold off on merging our work together, for example:

1. Right now we can't merge to new-dawn without thorough reviews, which is causing us to work in separate fragmented PRs, only dealing and updating PRs as ones make it through review
2. When we make big structural changes we need to update/deploy our packages to npm, however some changes need to be done using workspace:* since our repo has many interdependencies and as far as I know only @drptbl can update npm
3. it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.
4. It will allow us to organize the v4 BETA release under 1 branch and do a thorough test prior to launch.

I know it's a bit of a pace change but I'd really appreciate if we can adopt this.

But how the new branch will resolve the conflicts?

[Seroxdesign]

How is it better to use different branch? There will be the same conflicts here and there right?

The reason I am pushing for us using the new-dawn-dev branch is so that we don't have to hold off on merging our work together, for example:

1. Right now we can't merge to new-dawn without thorough reviews, which is causing us to work in separate fragmented PRs, only dealing and updating PRs as ones make it through review
2. When we make big structural changes we need to update/deploy our packages to npm, however some changes need to be done using workspace:* since our repo has many interdependencies and as far as I know only @drptbl can update npm
3. it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.
4. It will allow us to organize the v4 BETA release under 1 branch and do a thorough test prior to launch.

I know it's a bit of a pace change but I'd really appreciate if we can adopt this.

But how the new branch will resolve the conflicts?

I explained it ^

TLDR:

1. faster merges because less review pressure
2. because faster merges we can work off the latest changes

It's like having a dev branch, have you ever used a dev branch? Because you're not the only one pushing code now we need to find a way to keep in sync.

[matstyler]

How is it better to use different branch? There will be the same conflicts here and there right?

The reason I am pushing for us using the new-dawn-dev branch is so that we don't have to hold off on merging our work together, for example:

1. Right now we can't merge to new-dawn without thorough reviews, which is causing us to work in separate fragmented PRs, only dealing and updating PRs as ones make it through review
2. When we make big structural changes we need to update/deploy our packages to npm, however some changes need to be done using workspace:* since our repo has many interdependencies and as far as I know only @drptbl can update npm
3. it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.
4. It will allow us to organize the v4 BETA release under 1 branch and do a thorough test prior to launch.

I know it's a bit of a pace change but I'd really appreciate if we can adopt this.

But how the new branch will resolve the conflicts?

I explained it ^

TLDR:

1. faster merges because less review pressure
2. because faster merges we can work off the latest changes

It's like having a dev branch, have you ever used a dev branch? Because you're not the only one pushing code now we need to find a way to keep in sync.

But it's not helping with the conflicts. It's not a solution if we will have another, not synchronised branch. Lets try to make the way we have better aligned :)

[Seroxdesign]

How is it better to use different branch? There will be the same conflicts here and there right?

The reason I am pushing for us using the new-dawn-dev branch is so that we don't have to hold off on merging our work together, for example:

1. Right now we can't merge to new-dawn without thorough reviews, which is causing us to work in separate fragmented PRs, only dealing and updating PRs as ones make it through review
2. When we make big structural changes we need to update/deploy our packages to npm, however some changes need to be done using workspace:* since our repo has many interdependencies and as far as I know only @drptbl can update npm
3. it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.
4. It will allow us to organize the v4 BETA release under 1 branch and do a thorough test prior to launch.

I know it's a bit of a pace change but I'd really appreciate if we can adopt this.

But how the new branch will resolve the conflicts?

I explained it ^ TLDR:

1. faster merges because less review pressure
2. because faster merges we can work off the latest changes

It's like having a dev branch, have you ever used a dev branch? Because you're not the only one pushing code now we need to find a way to keep in sync.

But it's not helping with the conflicts. It's not a solution if we will have another, not synchronised branch. Lets try to make the way we have better aligned :)

You're being pedantic, dev branches are a well defined, useful standard that is popular and widely adopted for a reason. The way you're working makes more work for me, and vice-versa.

For example, I already got things working on Windows, so if you're working off the latest branch you can just adopt the solution so I don't have to jump in and clean after you, or get my work blocked for another x time because windows works in 1 wallet and not another.

There are people using new-dawn 0.0.1-alpha.7, progress is made much slower there, which is why we are not in sync, having a dev branch like everyone else is a clean and simple solution. (:

[matstyler]

How is it better to use different branch? There will be the same conflicts here and there right?

The reason I am pushing for us using the new-dawn-dev branch is so that we don't have to hold off on merging our work together, for example:

1. Right now we can't merge to new-dawn without thorough reviews, which is causing us to work in separate fragmented PRs, only dealing and updating PRs as ones make it through review
2. When we make big structural changes we need to update/deploy our packages to npm, however some changes need to be done using workspace:* since our repo has many interdependencies and as far as I know only @drptbl can update npm
3. it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.
4. It will allow us to organize the v4 BETA release under 1 branch and do a thorough test prior to launch.

I know it's a bit of a pace change but I'd really appreciate if we can adopt this.

But how the new branch will resolve the conflicts?

I explained it ^ TLDR:

1. faster merges because less review pressure
2. because faster merges we can work off the latest changes

It's like having a dev branch, have you ever used a dev branch? Because you're not the only one pushing code now we need to find a way to keep in sync.

But it's not helping with the conflicts. It's not a solution if we will have another, not synchronised branch. Lets try to make the way we have better aligned :)

You're being pedantic, dev branches are a well defined, useful standard that is popular and widely adopted for a reason. The way you're working makes more work for me, and vice-versa.

For example, I already got things working on Windows, so if you're working off the latest branch you can just adopt the solution so I don't have to jump in and clean after you, or get my work blocked for another x time because windows works in 1 wallet and not another.

There are people using new-dawn 0.0.1-alpha.7, progress is made much slower there, which is why we are not in sync, having a dev branch like everyone else is a clean and simple solution. (:

I am not saying about dev branch approach but about conflicts. You said you want to avoid them. I am just saying another branch will not resolve any conflict.

Furthermore how merging this branch somewhere else will help you will the conflicts in the future?