What does the --target flag on Playwright's codegen command change about the script it emits?

`codegen` is the command that opens a browser, follows what you do in it, and prints the equivalent script. The `--target` flag decides what that printed script looks like. ## What the flag selects `--target` changes only the **rendering** of the recorded steps: which language they are written in, and which test harness they are wrapped in. The same click on *Get quote* comes out as `page.get_by_role("button", name="Get quote").click()` under a Python target and as `page.getByRole('button', { name: 'Get quote' }).click()` under a JavaScript one. Nothing about which element is chosen depends on the target. The accepted values group into the language bindings Playwright ships, plus a harness variant for each: - `playwright-test` — the default, a `@playwright/test` file with `test(...)` and the `page` fixture; - `javascript` — a plain script that launches a browser itself; - `python`, `python-async`, `python-pytest`; - `java`, `java-junit`; - `csharp`, `csharp-nunit`, `csharp-mstest`. Pair it with `-o <file>` to write the result to disk instead of the terminal, and pass the start URL as the final argument so the browser opens on the page you want to record. ## Why it matters during a port, and how much A team moving a legacy insurance-quote suite usually has two open questions in the first week: *what does an idiomatic test look like in our language on the new stack*, and *what locator should we be writing for this control*. `--target` answers both cheaply, in the language the team is actually keeping. | It is good for | It is not for | |---|---| | a first working file in the destination language | translating your existing cases | | seeing the locator style for an unfamiliar control | choosing your suite's locator conventions | | checking a flow still works while you port it | producing tests you commit unedited | | showing the harness skeleton to a team new to it | carrying over data setup or assertions | The honest framing in an interview is that codegen output is a **starting point, not a port**. It records the steps you performed, so it captures a happy path with your ad-hoc data baked in, and the assertions it produces are the ones you asked for while recording rather than the ones the original test made. Committing raw generated files is how a migrated suite ends up with a hundred near-identical scripts nobody can maintain. ## A sane way to use it in a migration 1. Record one representative flow in the target language and read the file, to fix the shape of the ported tests. 2. Keep the locators it suggests where they are role- or label-based, and replace the brittle structural ones with the test attributes your application already exposes. 3. Port the *original* test's data, preconditions and assertions in by hand; the recording gives you the navigation, not the intent. 4. Throw the generated file away once its structure has been absorbed, rather than growing the suite by recording every case. ## Version and language notes The target list above is what Playwright 1.63 accepts; treat it as version-sensitive and check `npx playwright codegen --help` on the version the team has pinned rather than trusting a remembered list. One practical consequence for a port is that the destination language does not have to be JavaScript at all: the same recorder can hand a Java or .NET team a file in their own language, which removes the "we must also learn Node" objection from the migration plan without changing anything about how the tests are written.