<h3 dir="auto">System info</h3>
<ul dir="auto">
<li>Playwright Version: [v1.31.1]</li>
<li>Operating System: [Windows 10]</li>
<li>Browser: [Chromium]</li>
<li>Other info:<br>
Command <code class="notranslate">npx playwright install chrome</code><br>
Log from Terminal:</li>
</ul>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="Downloading Google Chrome
Installing Google Chrome
ERROR: failed to install Google Chrome
Failed to install browsers     
Error: Failed to install chrome"><pre class="notranslate"><code class="notranslate">Downloading Google Chrome
Installing Google Chrome
ERROR: failed to install Google Chrome
Failed to install browsers     
Error: Failed to install chrome
</code></pre></div>
<p dir="auto">Chrome is installed on my machine.</p>
<p dir="auto">Unable to run tests on Chrome Browser.</p>
<h1 dir="auto">Table of Contents</h1>
<ol dir="auto">
<li><a href="#org652b63f">(Feature Request) The case for installing Playwright globally on a machine</a>
<ol dir="auto">
<li><a href="#org78e7e0f">problem statement</a></li>
<li><a href="#org7c6c4f3">use cases</a>
<ol dir="auto">
<li><a href="#orgc293c8e">1. Using Playwright like a standard installed application.</a></li>
<li><a href="#org9b3fc7f">2. Situations like classrooms and labs where a single installation of Playwright is simpler to maintain.</a></li>
<li><a href="#org58d6ad4">3. Docker images that do not bake in the tests</a></li>
</ol>
</li>
<li><a href="#orgc5e47c9">close to technically feasible</a></li>
</ol>
</li>
</ol>
<p dir="auto"><a id="user-content-org652b63f"></a></p>
<h1 dir="auto">(Feature Request) The case for installing Playwright globally on a machine</h1>
<p dir="auto"><a id="user-content-org78e7e0f"></a></p>
<h2 dir="auto">problem statement</h2>
<p dir="auto">Based on my understanding, there are 3 layers to utilizing Playwright<br>
L1. playwright proper or what is known as @playwright/test<br>
L2. browser dependencies<br>
L3. tests</p>
<p dir="auto">The current installation process of Playwright exposes all 3 layers because L2 is a specific step that needs<br>
to be performed for each Playwright folder. This is ideal for developers because it allows them to deal with<br>
problems of each layer appropriately by installing L1 and L2 in each development folder.</p>
<p dir="auto">However, there is also a case to be made for combining L1 and L2, as a single step and presenting Playwright<br>
as a global testing tool.</p>
<p dir="auto"><a id="user-content-org7c6c4f3"></a></p>
<h2 dir="auto">use cases</h2>
<p dir="auto"><a id="user-content-orgc293c8e"></a></p>
<h3 dir="auto">1. Using Playwright like a standard installed application.</h3>
<p dir="auto">An analogous example : we install Word and then invoke it on any file anywhere on our PC. There is no special dependencies<br>
that the user need to do.</p>
<p dir="auto">The Playwright and browser support is part of one environment that the use of PATH is sufficient</p>
<p dir="auto">This results in only one copy of Playwright and browser support layer needed instead of being duplicated in each Playwright folder.</p>
<p dir="auto">This also allows many test sources to be run against a single Playwright install.</p>
<p dir="auto"><a id="user-content-org9b3fc7f"></a></p>
<h3 dir="auto">2. Situations like classrooms and labs where a single installation of Playwright is simpler to maintain.</h3>
<p dir="auto">This is where one person/teacher deals with the install of Playwright and the browser dependencies and all users/students point<br>
to that installation and just write tests.</p>
<p dir="auto"><a id="user-content-org58d6ad4"></a></p>
<h3 dir="auto">3. Docker images that do not bake in the tests</h3>
<p dir="auto">So instead of creating custom docker images from Docker Focal, each with its own copy of tests,<br>
the Docker image can reference arbitary test volumes and therefore only one image ( but as many containers as needed ) is needed.</p>
<p dir="auto">The advent of WSL2 allows the running of Linux apps that interopreate with Windows in a seamless manner. Accessing Playwright via Docker is an extension of this type of seamless use.</p>
<p dir="auto">See <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="1236583340" data-permission-text="Title is private" data-url="https://github.com/microsoft/playwright/issues/14179" data-hovercard-type="issue" data-hovercard-url="/microsoft/playwright/issues/14179/hovercard" href="https://github.com/microsoft/playwright/issues/14179">#14179</a></p>
<p dir="auto"><a id="user-content-orgc5e47c9"></a></p>
<h2 dir="auto">close to technically feasible</h2>
<p dir="auto">There are also several technical reasons that suggests that installing Playwright globally close to being feasible.</p>
<ol dir="auto">
<li>
<p dir="auto">npm supports installing packages globally<br>
However, installing Playwright globally is not currently supported.</p>
</li>
<li>
<p dir="auto">Playwright already has functionality that seems to be allowing running tests in other directories<br>
that is,  –config {dir} or testDir in configuration files<br>
The current problem appears to be if the {dir} is outside the Playwright folder, the tests cannot run properly.</p>
<p dir="auto">See <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="1229998951" data-permission-text="Title is private" data-url="https://github.com/microsoft/playwright/issues/14039" data-hovercard-type="issue" data-hovercard-url="/microsoft/playwright/issues/14039/hovercard" href="https://github.com/microsoft/playwright/issues/14039">#14039</a></p>
</li>
</ol>