You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As for the conversation going on #2286, it would be beneficial to restore support of the Microsoft.Playwright.CLI global tool.
In #3106 it was stated that the tool wouldn't know which version to download and install in case of a solution with projects using multiple versions of PW.
This could be solved by requiring a --version argument in such cases. In case multiple projects use the same version of PW, that version should be installed.
Example
# assume single version used in solution
$ playwright -p path/to/solution.sln install --with-deps
# specify version
$ playwright -p path/to/solution.sln install --with-deps --version 1.48
Motivation
Most of the conversation is already happening in #2286
In short, the current flow is not aligned to the general .NET experience.
# current
$ dotnet restore
$ pwsh bin/Debug/net8.0/playwright.ps1 install
$ dotnet test
# usual
$ dotnet tool install -g something
$ dotnet build
$ dotnet test
Using the tool makes it easier to create scripts as they don't require knowledge of the directory layout of the solution. This is helpful when creating build steps to be shared across multiple pipelines.
Also: the amount of time I had a junior stuck because the documentation says
$ pwsh bin/Debug/netX/playwright.ps1 install
The text was updated successfully, but these errors were encountered:
🚀 Feature Request
As for the conversation going on #2286, it would be beneficial to restore support of the Microsoft.Playwright.CLI global tool.
In #3106 it was stated that the tool wouldn't know which version to download and install in case of a solution with projects using multiple versions of PW.
This could be solved by requiring a
--version
argument in such cases. In case multiple projects use the same version of PW, that version should be installed.Example
Motivation
Most of the conversation is already happening in #2286
In short, the current flow is not aligned to the general .NET experience.
Using the tool makes it easier to create scripts as they don't require knowledge of the directory layout of the solution. This is helpful when creating build steps to be shared across multiple pipelines.
Also: the amount of time I had a junior stuck because the documentation says
The text was updated successfully, but these errors were encountered: