Question 1

What is the difference between named and default exports, and which do you prefer?

Accepted Answer

A file can have any number of named exports and the import name must match exactly; a default export is one per file and the importer may call it whatever it likes. In test projects I prefer named exports because: (1) the same class appears under the same name everywhere — searching for LoginPage finds every use; (2) the IDE's auto-import and rename refactoring work correctly; (3) exporting several related things from one file (class + constant + type) becomes natural. Default exports have their place — playwright.config.ts default-exports its config object — but that should be the exception, not the rule.

Question 2

What is the difference between ESM and CommonJS, and when does it cause problems in a test project?

Accepted Answer

CommonJS is Node's historical system: require()/module.exports, synchronous and dynamic loading. ESM is the language's own standard: import/export, static loading, top-level await. Trouble usually appears in mixed projects: someone adds "type": "module", then an old helper using require() throws require is not defined in ES module scope; or the reverse, a CommonJS file cannot require() an ESM-only package. My practical approach: keep the project on one system (ESM + TypeScript for new Playwright projects), mark exceptions explicitly with .cjs/.mjs, and make sure module/moduleResolution in tsconfig.json matches the runtime.

Question 3

How do you detect and fix a circular import?

Accepted Answer

The symptoms: an imported value is unexpectedly undefined, the Class extends value undefined is not a constructor error, or a module that only works depending on import order. Detection: ESLint's import/no-cycle rule (the simplest automated route) or a tool like madge --circular. My fix priority: (1) correct the direction of dependency — a parent class or shared helper must never import a concrete page; (2) extract shared types and constants into their own types.ts/constants.ts; (3) limit internal use of barrel files — modules import each other directly and index.ts faces outward only; (4) only as a last resort, a dynamic await import(...) inside a function. The underlying point: a circular import is usually a design problem, not a technical glitch.

Question 4

How would you organise the import structure of a large test suite?

Accepted Answer

I would split it into layers and point every dependency one way: tests/ → pages/ and fixtures/ → helpers/ and data/ → types/ and constants/. A lower layer never imports a higher one — that single rule removes most circular dependencies. I set up paths aliases in tsconfig.json (@pages/, @helpers/), because paths like ../../../pages break during refactoring; and I check upfront which other tools (ESLint, Jest, ts-node) also need those aliases configured — the most commonly forgotten step. Barrel files stay only at a layer's outer boundary. For enforcement: the ESLint rules import/no-cycle, import/order, and no-restricted-imports for cross-layer bans. Finally, loading heavy, rarely used modules through a dynamic import() improves cold start.

Aspect	ESM (the modern standard)	CommonJS (Node's legacy system)
Syntax	import / export	require() / module.exports
How it is enabled	"type": "module" in package.json, or the .mjs extension	Node's default; the .cjs extension
Loading	static — tools can see dependencies ahead of time	dynamic — require() can be called anywhere
Top-level await	supported	not supported
File extension in imports	required in pure ESM ('./api.js')	not required
Mixing them	can import CJS	cannot require() ESM (only dynamic import())

Modules: import and export

📚 Sources and documentation