Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monorepo support #15

Open
sand4rt opened this issue Oct 10, 2023 · 4 comments
Open

Monorepo support #15

sand4rt opened this issue Oct 10, 2023 · 4 comments

Comments

@sand4rt
Copy link
Contributor

sand4rt commented Oct 10, 2023

Thank you for this awesome library <3

When attempting to run the tests in my project (located at https://github.com/sand4rt/playwright-ct-web), I encountered the following error: neotest-playwright: Error: Unable to locate playwright binary. Expected to find it at: /playwright-ct-web/node_modules/.bin/playwright.

Was able to resolve this issue by navigating to ct-web-lit, opening Vim, and running the tests from there.

Would it be possible to auto locate the playwright binary in mono repo's?

Related to: marilari88/neotest-vitest#23

@thenbe
Copy link
Owner

thenbe commented Oct 11, 2023

Thanks for filing an issue. Supporting pnpm was my intention when I first created this. In fact, the project I was testing against as I was working on this adapter was a pnpm monorepo. However, I failed to find lua equivalents of the tools that would make it relatively simple to implement this feature (eg. find-up).

Although I wasn't interested in writing all that logic from scratch, I still did not want to have to exit vim and cd into the subrepo to access my tests every time. So I settled for exposing these config values: get_cwd, get_playwright_binary, and get_playwright_config to allow the adapter to at least be manually configured to support a pnpm repo. At the time, I was heavily working on a single repo so it made sense for me to add some custom logic in my vim config just for this repo.

-- it looked something like this
local current_path = vim.loop.cwd()
local in_special_repo = current_path:match("projects/myspecialrepo") ~= nil
if in_special_repo then
  local special_opts = {
    options = {
      get_cwd = function()
        return current_path .. "/packages/test"
      end,

      get_playwright_config = function()
        return current_path .. "/packages/test/playwright.config.ts"
      end,

      get_playwright_binary = function()
        return current_path .. "/packages/test/node_modules/.bin/playwright"
      end,
    },
  }
  require("neotest").setup(
    { adapters = { require("neotest-playwright").adapter(special_opts) } }
  )
else
  require("neotest").setup(
    { adapters = { require("neotest-playwright").adapter(normal_opts) } }
  )
end

Would this work for your use case?

@sand4rt
Copy link
Contributor Author

sand4rt commented Oct 11, 2023

Thanks for your reply. While this is certainly a step in the right direction. it would be highly beneficial if this functionality could be supported without the need for additional configuration.

I frequently switch between projects, each with its own distinct folder structure. When it comes to Playwright component testing, I often work with multiple packages, each containing Playwright tests and separate playwright.config.ts config's. Manually adjusting the paths for each package every time is a lot of manual work. Additionally, it would be valuable to have an overview of all the tests in the Neotest summary. This won't work if you can only specify one playwright.config.ts file as far as i know.

Example structure of the project work in:

  • /ComponentLibrary
  • /ComponentLibrary/packages/button/playwright.config.ts
  • /ComponentLibrary/packages/label/playwright.config.ts
  • /ComponentLibrary/packages/icon/playwright.config.ts
  • /ComponentLibrary/packages/input/playwright.config.ts

*an example can be found here as well: https://github.com/justeattakeaway/pie/tree/main/packages/components

@thenbe
Copy link
Owner

thenbe commented Oct 11, 2023

Yeah I can see how that would be inconvenient. Do you (or anyone reading this in the future) have any thoughts or opinions on implementation? To be clear, I'm referring to 1 at the moment, as 1 would probably need to come first before any work can start on 2.

  1. In a pnpm monorepo root, detect and run tests that are located in a "subrepo". (without requiring manual configuration like the one seen here)
  2. Support multiple playwright.config.ts at the same time

To make step 1 work, we'd need to rely on an external dependency like fd, I think. Unless there's a cleaner solution (that can search fast and respect .gitignore) that I'm not aware of?

Do you mostly have a predictable repo structure like the example you specified? As in, your playwright.config.ts is always at monoreporoot/*/*/playwright.config.ts? (as opposed to deeper/unpredictable nesting like the sveltekit monorepo)

Finally, would you be able to test if the vscode playwright extension covers your use case? Maybe there's some inspiration to be had here.

@sand4rt
Copy link
Contributor Author

sand4rt commented Oct 11, 2023

To make step 1 work, we'd need to rely on an external dependency like fd, I think. Unless there's a cleaner solution (that can search fast and respect .gitignore) that I'm not aware of?

I'm not sure, I'm quite new to Lua and Vim :/

Do you mostly have a predictable repo structure like the example you specified? As in, your playwright.config.ts is always at monoreporoot///playwright.config.ts? (as opposed to deeper/unpredictable nesting like the sveltekit monorepo)

playwright.config.ts is always inside the root of the package as far as i know, however it is also possible to rename playwright.config.ts and use npx playwright test -c playwright-ct.config.ts for when you have the e2e tests and component tests inside the same package.

Finally, would you be able to test if the vscode playwright extension covers your use case? Maybe there's some inspiration to be had here.

Yeah, this works in vscode with the Playwright extension: https://github.com/microsoft/playwright-vscode/tree/main

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants