Question 1

Named export ilə default export fərqi nədir, hansına üstünlük verirsən?

Accepted Answer

Named export bir fayldan istənilən qədər ola bilər və import edərkən ad dəqiq eyni olmalıdır; default export faylda bir dənədir və import edən tərəf ona istədiyi adı verə bilər. Test layihələrində named export-a üstünlük verirəm, çünki: (1) eyni class hər yerdə eyni adla görünür — LoginPage axtarışı bütün istifadələri tapır; (2) IDE-nin avtomatik import və avtomatik yenidənadlandırma funksiyaları düzgün işləyir; (3) bir fayldan bir neçə əlaqəli şeyi (class + sabit + tip) ixrac etmək təbii olur. Default export-un yeri var — məsələn, playwright.config.ts konfiqurasiya obyektini default ixrac edir — amma bu, qayda yox, istisna olmalıdır.

Question 2

ESM və CommonJS fərqi nədir və bu, test layihəsində nə vaxt problem yaradır?

Accepted Answer

CommonJS — Node-un tarixi sistemi: require()/module.exports, sinxron və dinamik yüklənmə. ESM — dilin öz standartı: import/export, statik yüklənmə, top-level await. Problem adətən qarışıq layihələrdə çıxır: "type": "module" əlavə edilir, sonra hansısa köhnə helper require() işlətdiyi üçün require is not defined in ES module scope xətası verir; və ya əksinə, CommonJS faylından yalnız ESM olan paketi require() etmək mümkün olmur. Praktik yanaşmam: layihəni bir sistemdə saxlamaq (yeni Playwright layihələrində ESM + TypeScript), istisna faylları .cjs/.mjs uzantısı ilə açıq işarələmək və tsconfig.json-dakı module/moduleResolution parametrlərinin runtime ilə uyğun olmasına diqqət etmək.

Question 3

Dairəvi importu necə aşkar edib düzəldirsən?

Accepted Answer

Əlamətlər: import edilən dəyər gözlənilmədən undefined olur, Class extends value undefined is not a constructor xətası, və ya modul yalnız import sırasından asılı olaraq işləyir. Aşkarlama: ESLint-in import/no-cycle qaydası (ən sadə və avtomatik yol) və ya madge --circular kimi alət. Düzəliş prioritetim: (1) asılılıq istiqamətini düzəltmək — valideyn class və ya ümumi helper heç vaxt konkret səhifəni import etməməlidir; (2) paylaşılan tip və sabitləri ayrıca types.ts/constants.ts faylına çıxarmaq; (3) barrel faylların daxili istifadəsini məhdudlaşdırmaq — modullar bir-birini birbaşa import etsin, index.ts yalnız xaricə baxsın; (4) yalnız son çarə olaraq funksiya daxilində dinamik await import(...). Prinsipial fikir: dairəvi import adətən dizayn problemidir, texniki nasazlıq deyil.

Question 4

Böyük test suite-ində import strukturunu necə təşkil edərdin?

Accepted Answer

Qatlara bölərdim və asılılıq istiqamətini bir tərəfə yönəldərdim: tests/ → pages/ və fixtures/ → helpers/ və data/ → types/ və constants/. Aşağı qat heç vaxt yuxarını import etmir — bu tək qayda dairəvi asılılıqların böyük hissəsini aradan qaldırır. tsconfig.json-da paths alias-ları qururam (@pages/, @helpers/), çünki ../../../pages kimi yollar refactoring zamanı sınır; həmçinin alias-ların Playwright-dan başqa hansı alətlərdə (ESLint, Jest, ts-node) konfiqurasiya olunmalı olduğunu əvvəlcədən yoxlayıram — bu, ən çox unudulan addımdır. Barrel faylları yalnız qatın xarici sərhədində saxlayıram. Nəzarət üçün ESLint qaydaları: import/no-cycle, import/order və qatlararası qadağalar üçün no-restricted-imports. Nəhayət, ağır və nadir istifadə olunan modulları dinamik import() ilə yükləmək cold start-ı yaxşılaşdırır.

Xüsusiyyət	ESM (müasir standart)	CommonJS (Node-un köhnə sistemi)
Sintaksis	import / export	require() / module.exports
Necə aktivləşir	package.json-da "type": "module" və ya .mjs uzantısı	Node-un defoltu; .cjs uzantısı
Yüklənmə	statik — alətlər asılılıqları əvvəlcədən görür	dinamik — require() istənilən yerdə çağırıla bilər
Top-level await	dəstəklənir	dəstəklənmir
Fayl uzantısı importda	təmiz ESM-də tələb olunur ('./api.js')	tələb olunmur
Qarışdırmaq	CJS-i import etmək olur	ESM-i require() etmək olmur (yalnız dinamik import())

Modullar: import və export

📚 Mənbələr və sənədlər