Lesson 1 of 86 min read
Why Playwright teams use TypeScript
TypeScript is JavaScript with types. You write almost the same code, but the editor checks it before the test runs. Most Playwright job descriptions ask for TypeScript, and Playwright itself is written in it.
Key takeaways
- 1TypeScript code is turned into JavaScript before it runs. Playwright does this for you automatically, so npx playwright test works on .ts files with no extra setup.
- 2Types catch mistakes while you type: a misspelled method (page.clik), a wrong argument (a number where text is needed) or a missing field in test data.
- 3Autocomplete is the everyday win: type page. and VS Code lists every method with its parameters and documentation.
- 4npm init playwright@latest asks 'TypeScript or JavaScript?' and creates playwright.config.ts, tests/example.spec.ts and a tsconfig-ready setup.
- 5Playwright runs tests even when there are type errors (it only strips types). Run npx tsc --noEmit in CI to fail the build on type errors.
The bug TypeScript catches before running
// JavaScript: runs, then fails 30 seconds later on CI
await page.getByRole('button', { name: 'Login' }).clik();
// TypeScript: red underline immediately in VS Code
// Property 'clik' does not exist on type 'Locator'. Did you mean 'click'?
// Wrong argument type
await page.waitForTimeout('2000');
// Argument of type 'string' is not assignable to parameter of type 'number'.
// Set up a new project
npm init playwright@latest -> choose TypeScript
npx playwright test -> runs .spec.ts files
npx tsc --noEmit -> type-check only (add to CI)
Go deeper
Expert notes beyond the basics
- 01
What happens when you run a .ts test
Playwright's test runner transforms each TypeScript file into JavaScript in memory (it strips the type annotations) and then runs it in Node.js. It does not type-check, which keeps runs fast. That's why a test with a wrong type can still run and fail at runtime. The editor (VS Code uses the TypeScript language server) and npx tsc --noEmit are where type checking happens. A good team setup: editor errors while writing, tsc --noEmit plus ESLint in the pull request pipeline, then playwright test.
- 02
Setting up VS Code for productive TypeScript
Install the official 'Playwright Test for VS Code' extension: it runs tests from the editor, records new tests with codegen, picks locators and shows a live browser. Turn on 'format on save' with Prettier. Hover over any Playwright method to read its documentation and parameters. Ctrl+Click (Cmd+Click) on a method jumps to its type definition, which is the fastest way to learn what options exist, for example every option of page.goto or locator.click.
- 03
The tsconfig.json settings that matter for tests
A test project needs only a few settings: "target": "ES2022", "module": "commonjs" or "ESNext", "strict": true (turns on strictNullChecks and noImplicitAny, the two settings that find most bugs), "noEmit": true (you never need compiled files) and "baseUrl"/"paths" if you want short imports like @pages/LoginPage. Playwright respects tsconfig paths. Start strict from day one; turning it on later in a big suite means fixing hundreds of errors.
- 04
JavaScript knowledge still matters
TypeScript adds types on top of JavaScript; it does not replace it. You still need arrays and their methods (map, filter, find, reduce), objects, template strings, destructuring, modules (import/export) and Promises. If you are weak in these, take the free JavaScript Basics course first. Interviewers often ask JavaScript questions (== vs ===, let vs const, what is a Promise) in a 'Playwright TypeScript' interview.
Common mistakes to avoid
- - Assuming a green Playwright run means no type errors. Playwright does not type-check; run tsc --noEmit too.
- - Fixing every red underline by adding : any or // @ts-ignore, which throws away the reason to use TypeScript.
- - Creating a project with JavaScript and renaming files to .ts later without a tsconfig or strict mode.
- - Skipping JavaScript fundamentals and getting stuck on Promises and array methods.
Try it yourself
Create a Playwright TypeScript project and prove type checking works: (1) create the project, (2) add a deliberate typo page.gotoo('/'), (3) show that playwright test still starts while tsc catches it, (4) add the scripts to package.json.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
Why would you choose TypeScript over JavaScript for Playwright?
Model answer
TypeScript catches errors such as typos, wrong argument types and missing test data fields in the editor before tests run, which saves CI time. It gives full autocomplete for Playwright's API, makes page objects and fixtures self-documenting, and makes refactoring safe in a large suite because the compiler shows every place that needs changing. Playwright supports it out of the box, so there is no extra build step.
- Q2
Is TypeScript compiled or interpreted?
Model answer
TypeScript is transpiled (compiled) into JavaScript, and the JavaScript is then run by Node.js or a browser. Browsers and Node don't run TypeScript directly. Playwright does the transpiling automatically in memory, so we just run npx playwright test.
- Q3
How do you enforce type checking in your Playwright pipeline?
Model answer
Add a typecheck script, tsc --noEmit, and run it with ESLint (typescript-eslint, including no-floating-promises) before the test job in CI. A type error or a missing await fails the pull request before any browser starts.
- Q4
What does strict mode do in tsconfig?
Model answer
It enables a group of stricter checks; the most important are noImplicitAny (every value must have a known type) and strictNullChecks (null and undefined must be handled explicitly). In tests, strictNullChecks catches cases like using an environment variable that might be undefined.
Knowledge check
+5 points
Your test has a type error. What does npx playwright test do?