✨ feat: MetaMask setup in Cypress #1157

matstyler · 2024-06-25T21:53:55Z

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

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

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

vercel · 2024-06-25T21:53:58Z

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 · 2024-06-26T14:32:26Z

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?

wallets/metamask/src/cypress/support/initMetaMask.ts

wallets/metamask/src/type/MetaMaskAbstract.ts

Seroxdesign · 2024-07-08T08:03:23Z

You forgot to git ignore the download directory

wallets/metamask/src/cypress/support/pages/OnboardingPage/importWallet.ts

Seroxdesign · 2024-07-09T08:42:51Z

Unit tests are failing
Does this include using cache for Cypress? Here is a potential setup to make this happen
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

matstyler · 2024-07-09T10:59:00Z

Unit tests are failing

Does this include using cache for Cypress? Here is a potential setup to make this happen

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

Yes, I pushed a few fixes today.
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 · 2024-07-09T11:14:07Z

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:

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
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
it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.
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.

Seroxdesign

I am not sure if there's a way for us to shift to using better relative imports, the ../../ pattern is pretty ugly and confusing, but it's not critical

.gitignore

wallets/metamask/src/cypress/MetaMask.ts

wallets/metamask/src/prepareExtension.ts

wallets/metamask/src/type/MetaMaskAbstract.ts

wallets/metamask/test/cypress/metamask.cy.ts

matstyler · 2024-07-09T11:29:19Z

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:

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

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

it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.

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 · 2024-07-09T12:51:22Z

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:

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

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

it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.

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:

faster merges because less review pressure
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 · 2024-07-09T12:57:44Z

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:

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

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

it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.

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:

faster merges because less review pressure

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 · 2024-07-09T13:00:30Z

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:

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

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

it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.

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:

faster merges because less review pressure

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 · 2024-07-09T13:10:05Z

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:

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

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

it will allow us to work closer together and consider each-other's work, to hopefully reduce wasteful merge conflicts.

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:

faster merges because less review pressure

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?

drptbl · 2024-07-10T22:22:01Z

.gitignore

@@ -37,6 +37,9 @@ test-results
 playwright-report
 playwright/.cache

+### Cypress
+wallets/metamask/downloads


use wallets/**/downloads

drptbl · 2024-07-10T22:23:42Z

wallets/metamask/cypress.config.ts

+    supportFile: 'src/cypress/support/e2e.{js,jsx,ts,tsx}',
+    testIsolation: false,
+    async setupNodeEvents(on, config) {
+      return installSynpress(on, config)


is installSynpress a good name here?
maybe configureSynpress would be better?

what do you think about "configureBeforeSynpress"?

wallets/metamask/package.json

wallets/metamask/src/prepareExtension.ts

drptbl · 2024-07-11T18:15:59Z

wallets/metamask/package.json

-    "build:cache": "synpress-cache test/wallet-setup",
-    "build:cache:headless": "synpress-cache test/wallet-setup --headless",
-    "build:cache:headless:force": "synpress-cache test/wallet-setup --headless --force",
+    "build:cache": "synpress-cache test/playwright/wallet-setup",


build:playwright:cache?

end goal will be to use it for both: Playwright and Cypress

drptbl · 2024-07-11T18:18:05Z

wallets/metamask/src/prepareExtension.ts

+    outputDir = ensureCacheDirExists()
+  } else {
+    outputDir = path.resolve('./', 'downloads')
+    outputDir = process.platform === 'win32' ? `file:\\\\\\${outputDir}` : outputDir


why making it complicated, instead of doing

outputDir = process.platform === 'win32' ? `file:\\\\\\${outputDir}` : path.resolve('./', 'downloads')

?

are you sure it will work?

drptbl · 2024-07-11T18:19:07Z

wallets/ethereum-wallet-mock/cypress.config.ts

@@ -10,7 +10,7 @@ export default defineConfig({
    fixturesFolder: 'src/cypress/fixtures',
    testIsolation: false,
    async setupNodeEvents(on, config) {
-      return installSynpress(on, config)
+      return configureBeforeSynpress(on, config)


configureBeforeSynpress?

why not
configureSynpress?

vercel bot deployed to Preview June 25, 2024 21:53 View deployment

feat: MetaMask setup in Cypress part 1

953c425

matstyler force-pushed the feat/metamask-with-cypress branch from d75027f to 953c425 Compare July 4, 2024 21:04

vercel bot deployed to Preview July 4, 2024 21:04 View deployment

github-advanced-security bot found potential problems Jul 4, 2024

View reviewed changes

Merge branch 'new-dawn' into feat/metamask-with-cypress

f789bff

vercel bot deployed to Preview July 5, 2024 21:13 View deployment

feat: wallet setup is working as expected

85ba034

vercel bot deployed to Preview July 7, 2024 21:54 View deployment

fix: gitignore cleanup

3f9e804

vercel bot deployed to Preview July 8, 2024 19:44 View deployment

github-advanced-security bot found potential problems Jul 8, 2024

View reviewed changes

fix: clean imports

e6b3e3e

vercel bot deployed to Preview July 8, 2024 22:02 View deployment

matstyler changed the title ~~feat: MetaMask setup in Cypress part 1~~ feat: MetaMask setup in Cypress Jul 8, 2024

matstyler marked this pull request as ready for review July 8, 2024 22:03

matstyler requested review from Seroxdesign and drptbl July 8, 2024 22:03

fix: export from metamask package

211ed62

vercel bot deployed to Preview July 8, 2024 22:08 View deployment

matstyler changed the title ~~feat: MetaMask setup in Cypress~~ ✨ feat: MetaMask setup in Cypress Jul 8, 2024

fix: dependencies issues

c6b098e

vercel bot deployed to Preview July 9, 2024 10:20 View deployment

fix: cleanup

35635e2

vercel bot deployed to Preview July 9, 2024 10:24 View deployment

Seroxdesign suggested changes Jul 9, 2024

View reviewed changes

matstyler requested a review from Seroxdesign July 9, 2024 13:10

drptbl requested changes Jul 10, 2024

View reviewed changes

fix: test scripts

cce84ba

vercel bot deployed to Preview July 11, 2024 11:57 View deployment

fix: format

a9c9436

matstyler requested a review from drptbl July 11, 2024 11:58

vercel bot deployed to Preview July 11, 2024 11:58 View deployment

drptbl requested changes Jul 11, 2024

View reviewed changes

matstyler requested a review from drptbl July 11, 2024 19:34

fix: renamed configureBeforeSynpress.ts to configureSynpress.ts

ebc419d

vercel bot deployed to Preview July 14, 2024 11:56 View deployment

fix: metamask output dir

8efa182

vercel bot deployed to Preview July 18, 2024 09:42 View deployment

drptbl approved these changes Jul 18, 2024

View reviewed changes

drptbl merged commit 5544f21 into new-dawn Jul 18, 2024
10 checks passed

drptbl deleted the feat/metamask-with-cypress branch July 18, 2024 19:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

✨ feat: MetaMask setup in Cypress #1157

✨ feat: MetaMask setup in Cypress #1157

matstyler commented Jun 25, 2024 •

edited

Loading

vercel bot commented Jun 25, 2024 •

edited

Loading

Seroxdesign commented Jun 26, 2024 •

edited

Loading

Seroxdesign commented Jul 8, 2024

Seroxdesign commented Jul 9, 2024 •

edited

Loading

matstyler commented Jul 9, 2024

Seroxdesign commented Jul 9, 2024

Seroxdesign left a comment

matstyler commented Jul 9, 2024

Seroxdesign commented Jul 9, 2024 •

edited

Loading

matstyler commented Jul 9, 2024

Seroxdesign commented Jul 9, 2024 •

edited

Loading

matstyler commented Jul 9, 2024 •

edited

Loading

drptbl Jul 10, 2024

drptbl Jul 10, 2024

matstyler Jul 10, 2024

drptbl Jul 11, 2024

matstyler Jul 11, 2024

drptbl Jul 11, 2024

matstyler Jul 11, 2024

drptbl Jul 11, 2024

✨ feat: MetaMask setup in Cypress #1157

✨ feat: MetaMask setup in Cypress #1157

Conversation

matstyler commented Jun 25, 2024 • edited Loading

Motivation and context

Does it fix any issue?

Other useful info

Quality checklist

vercel bot commented Jun 25, 2024 • edited Loading

Seroxdesign commented Jun 26, 2024 • edited Loading

Seroxdesign commented Jul 8, 2024

Seroxdesign commented Jul 9, 2024 • edited Loading

matstyler commented Jul 9, 2024

Seroxdesign commented Jul 9, 2024

Seroxdesign left a comment

Choose a reason for hiding this comment

matstyler commented Jul 9, 2024

Seroxdesign commented Jul 9, 2024 • edited Loading

matstyler commented Jul 9, 2024

Seroxdesign commented Jul 9, 2024 • edited Loading

matstyler commented Jul 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

matstyler commented Jun 25, 2024 •

edited

Loading

vercel bot commented Jun 25, 2024 •

edited

Loading

Seroxdesign commented Jun 26, 2024 •

edited

Loading

Seroxdesign commented Jul 9, 2024 •

edited

Loading

Seroxdesign commented Jul 9, 2024 •

edited

Loading

Seroxdesign commented Jul 9, 2024 •

edited

Loading

matstyler commented Jul 9, 2024 •

edited

Loading