Closed Aghassi closed 1 month ago
We can probably respect environment variable as an alternative.
Yeah we could definitely do an environment variable. Then we could export that into process.env
from our configuration or runner such that it gets used. The main bit is we have to make sure that for folks on Node 18 we pass down the process.env
correctly (which looks like it is already handled here https://github.com/microsoft/playwright/blob/main/packages/playwright/src/common/configLoader.ts#L346-L361)
This also applies to this area https://github.com/microsoft/playwright/blob/main/packages/playwright-core/src/server/trace/viewer/traceViewer.ts#L69 so the viewer shows the appropriate source code
Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors.
If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated.
🚀 Feature Request
When running playwright with
ibazel
(https://github.com/bazelbuild/bazel-watcher) the process will not be serving files from the repo, but from another place on disk. It would be nice to support passing a custom opening function via the playwright config to allow developers to overwrite the file location that is used to open in vscode. Without this, the path will be under/private/....
by default as oppose to relative to the repo working directory.Example
and then in
uiMode.ts
reference this function if it exists, otherwise use the default logichttps://github.com/microsoft/playwright/blob/main/packages/playwright/src/runner/uiMode.ts#L96
Motivation
Make playwright running under bazel more seamless for developers so they don't have to care about the nuances of what bazel is doing and get a more "native" playwright experience. This would benefit other build tools like Buck as well.