[Feature] More intuitive setup and installation of Playwright

[Swimburger]

I'm a fan of PowerShell, but I think having to add Microsoft.Playwright.NUnit or a similar package, then build your project, then execute a PowerShell script that you can find in the bin/something...something/playwright.ps1 is not the ideal experience or the experience .NET developers expect. It works great tho!

I was hoping the Playwright setup experience could be more in line with what we expect as .NET developers.
I'm not an expert on MSBuild and still new to Playwright, so call me out if I'm off base!

When installing any Playwright NuGet package, I'd expect the installation to modify the MSBuild project file, and the MSBuild project file would setup all of Playwright the first time.
I'm not sure if Playwright updates its dependencies automatically over time, but if it did, I'd expect that to be checked for and updated during build. This could also be a standalone MSBuild target.

Alternatively, I think Playwright may also be a good fit for a global tool, or a local tool like the ef core tool.
Then inside the project, you may be able to run dotnet playwright init or dotnet playwright update.

Based on the NuGet package and MSBuild target described above, I'd expect there to be additional .NET templates for NUnit, MsTest, and xUnit. These templates would be the most intuitive ways to get started with Playwright and also to be reused for .NET IDEs like Visual Studio, VS Code, and Rider.

[mxschmitt]

Sounds related to #2213 which includes templates for vs, vsc and dotnet new.

[Swimburger]

There's definitely some overlap there! 👍

However, I think it makes sense to improve the installation mechanism without using templates as well, in case you're starting from a console app and do not plan to use a testing library.
This would make it more intuitive to add Playwright to other testing libraries outside of the big three (xUnit, NUnit, MsTest)

[timheuer]

In a $100 survey for Playwright for .NET I'd use $70 of my budget for this. The process today doesn't appear to put me on the path of success...

This process is just not how .NET developers expect things to work. To "build" a project to get a tool to be able to install things that are now really global (not project-specific) is a super odd flow. We need the post-install-nuget dependency to do more work, or to @Swimburger's point to have a combination of steps (global tool) to do the thing. The nuget package for the Test project shouldn't be the delivery for global tools IMO.

[pavelfeldman]

I'd need to pass on your $70 for the sake of our users. The reality is that we've arrived at where we are based on experience and the feedback from the field. We were installing on build, we used to have the dotnet tool, etc. We had to walk away from those because they were creating more problems than they were solving. Yes, we are different from a typical .NET application, but our use-cases are also different. Once you start deploying the tests to CI, use Playwright Containers with pre-installed browsers and dependencies, manage system dependencies installation on Linux, manage Playwright and Playwright Browsers updates in production, you'll see why the things are the way they are.

Templates and NUnit / MSTest integration are a different story, we are working on improving those!

[Swimburger]

What about the dependency on PowerShell? Could that be avoided?
The PowerShell file loads the Playwright DLL and invokes the Program.Main method:

#!/usr/bin/env pwsh

$PlaywrightFileName = Join-Path $PSScriptRoot "Microsoft.Playwright.dll"
[Reflection.Assembly]::LoadFile($PlaywrightFileName) | Out-Null
exit [Microsoft.Playwright.Program]::Main($args)

Would it make sense to run the DLL instead of the PowerShell script?
I'd expect dotnet Microsoft.Playwright.dll to do the same as the PowerShell script, but it does error.

[timheuer]

Yes, we are different from a typical .NET application, but our use-cases are also different. Once you start deploying the tests to CI, use Playwright Containers with pre-installed browsers and dependencies, manage system dependencies installation on Linux, manage Playwright and Playwright Browsers updates in production, you'll see why the things are the way they are.

I don't think the use case is much different from a bunch of other things in the ecosystem...you have some pre-reqs that must be satisfied for Playwright to work. Burying the acquisition of those in a dotnet build in order just to get the expansion of the nuget package into a random bin directory to then install those pre-reqs. It's the anti-pattern of NuGet and .NET and we should work together on either improving the NuGet post-experience (sadly we used to have this), or other means.

I would love to understand why this pattern solves things better for CI -- and would expect pre-installed containers to not need this at all? That part confused me why this makes it any better as the docs indicate the process is the same.

[pavelfeldman]

Would it make sense to run the DLL instead of the PowerShell script?

You can do that today if you'd like to install browsers programmatically.

I would love to understand why this pattern solves things better for CI -- and would expect pre-installed containers to not need this at all? That part confused me why this makes it any better as the docs indicate the process is the same.

I feel like we have a rather high-level, even a theoretical debate over a cosmetic detail. Could you share more on your test project configuration, how you run it and why you don't want to see a utility for manually fetching the required browsers. Playwright customers are often interested in better means of running tests in parallel, reusing authenticated state, running browsers in diverse containers and settings. They don't really focus on ability to install with 3 commands vs 2 commands. In order for us to prioritize this request, we need to better understand where it is coming from.

[pavelfeldman]

you have some pre-reqs that must be satisfied for Playwright to work

These pre-requisites are up to the user. The manual post-installation step is required to fetch the browser binaries matching the OS and process architecture. The set of the browsers is up to the user, not Playwright. I don't think NuGet can solve any of that.

-- adding

Even if NuGet allows downloading OS-specific binaries like pypi at some point (which as I understand is against the portability considerations), we won't want to create dozens of packages representing these browser binaries. That's simply too much of the maintenance overhead for us. And we won't want users to replicate them over and over for their local projects. That's >1G per the browser set, imagine you have 30 projects on your system - it adds up.

[timheuer]

why you don't want to see a utility for manually fetching the required browsers.

Oh I didn't mean that...to the contrary, I think that is valid utility -- I'm only focused on the UX. Relying on a \bin output for a utility of such is not a pattern we have in .NET...that's why we have global/local tools.

The manual post-installation step is required to fetch the browser binaries matching the OS and process architecture

Right, a global/local tool achieves this same and is more of the pattern for a .NET customer. I meant NuGet used to have a method of post-NuGet install being able to run commands...it no longer does.

And we won't want users to replicate them over and over for their local projects. That's >1G per the browser set, imagine you have 30 projects on your system - it adds up.

Totally agree...the pattern right now. The .NET SDK team has heard this feedback of multiple installs of our bits as well :-). It definitely adds up. In situations where there is multi-targeting, the current step also duplicates everything in \bin for each target (not talking about browsers)...so a single project multi-targeted for different version of .NET has multiple .playwright folders duplicating unnecessarily the contents (a secondary target duplicates my disk output now to 134MB).

I sent you a mail internally to better understand a bit 'offline' than here to know where .NET may be failing the workflow you've tried before. I don't debate the need for the CLI commands, the benefit, the constraints you note about browser acquisition, etc. I just think those can all be accomplished with a better UX for .NET developers.

[Swimburger]

You can do that today if you'd like to install browsers programmatically.

I see you can do this via the .NET API, but that's not what I mean.
If the PowerShell script is invoking the Program.Main method from the Microsoft.Playwright.dll, wouldn't you be able to do dotnet exec Microsoft.Playwright.dll or dotnet Microsoft.Playwright.dll. Or if you converted it into an executable binary, you could directly invoke Microsoft.Playwright?
(This doesn't work for some reason even though the PowerShell script and dotnet exec should do the same thing I think)

While there's only 3 lines to install Playwright, you do have to install PowerShell on your machine before running the third line, assuming it's not already on the machine. There's probably a good reason for involving PowerShell that I'm not aware off, but if there isn't, then not using PowerShell would be an improvement to the UX, as you'd not need to install it and keep it patched.

[pavelfeldman]

Let's keep it open to collect upvotes!

[AngelMunoz]

I just found this myself as well last time I tried it I was using the CLI tool which was bizarre for me as well. A global CLI tool that requires a project build to work... that's now that I would expect, specially when the node.js experience is quite smooth (npx playwright install like a .NET global tool)

I expected the global CLI tool to at minimum (and sometimes even at most) to just install the browsers
because my builds and F# scripts failed just because playwright browsers were not installed nothing else, once I ran npx playwright install things just worked and I could live with that

Now I come back and find that I need to run powershell scripts? which are generated after build?

That's simply too bizarre for me to be honest I'd prefer to have a global CLI tool that's just a wrapper over npx playwright install if that would let me do the following

dotnet tool restore
dotnet playwright install
dotnet build # or test

I don't think this is a cosmetic issue, while I know every project is different I find it hard to justify that I need to modify my .NET workflow just because a library seems to have weird requirements

Now I'm not sure how my wording is for this feedback but I certainly have no intention to annoy anyone it is just my raw experience with this tool from a few minutes ago after a couple of months away from it. The install experience hasn't been there from the get go, once we're past that things just work very nicely and smooth, it is a very sweet library to work with

Extra: It would be nice to pin this issue to make it more visible

[304NotModified]

Agree with this. I tried raising the same issue with #2239, but I guess it wasn't clear.

IMO this is far more important than all the new features (asserts etc) and 2nd is the large nodejs (#1850)

[IanChamberlain-SMS]

For Visual Studio the user experience should be:

1. Create a test project (Nunit/xUnit/MSTest whatever)
2. Add Nuget dependency for Playwright
3. Write Test Code
4. Run Tests

This experience currently fails because browsers aren't installed.
By default it should check to see if the browser specified has been installed and if not install it or alternatively use the Users Default Browser if it is supported.