Salvo

Salvo

WFN Üye
Konular
1,714
Mesajlar
1,736
Çözüm
0
Ticaret Puanı
0
Üyelik
6 Ay 15 Gün
Konum
İstanbul
Web Sitesi
Yok
Alanı
Belirtmemiş
1/1
Konu sahibi
İlk olarak hata mesajındaki modül yolunun türünü ayırın: ./ veya ../ ile başlayan yol yanlış dosya konumuna, paket adıyla başlayan yol eksik/yanlış kuruluma ya da paket dışa aktarımına, @/... gibi özel bir takma ad ise tsconfig.json ile çalışma zamanının uyuşmamasına işaret eder. Dosya adını ve büyük-küçük harfleri düzeltin, gerekli paketi projenin kök dizininde kurun, tsconfig.json içindeki modül çözümleme ayarlarını kullandığınız çalışma ortamına göre düzenleyin ve ardından npx tsc --noEmit komutuyla sonucu kontrol edin. Hata devam ederse --traceResolution çıktısı TypeScript’in hangi yolları denediğini gösterir.

Hata hangi import satırında oluşuyor?​


Önce hata mesajındaki import ifadesini ve dosyanın gerçek konumunu karşılaştırın. Örneğin src/index.ts içinden src/utils/logger.ts dosyasını çağırıyorsanız doğru göreli yol şudur:

Kod: 
import { logger } from "./utils/logger";

index.ts dosyası src/components klasöründeyse aynı dosyaya ulaşmak için yol bir üst dizine çıkmalıdır:

Kod: 
import { logger } from "../utils/logger";

Cannot find module './utils/logger' hatası bu durumda çoğunlukla dosyanın yanlış klasörde aranması anlamına gelir. Dosya gerçekten mevcut olsa bile şu ayrıntıları da kontrol edin:
  • Dosya adındaki büyük-küçük harfler import ile aynı mı? Logger.ts ile logger.ts, büyük-küçük harfe duyarlı sistemlerde farklı dosyalardır.
  • Dosya uzantısı gerçekten .ts, .tsx, .js, .mts veya .cts mi?
  • Import satırındaki göreli yol, import yapan dosyaya göre mi yazıldı?
  • Dosya, exclude veya yanlış bir rootDir ayarı nedeniyle derleme kapsamının dışında mı?
Göreli importlarda önce uzantıyı rastgele ekleyip çıkarmak yerine projenizin modül sistemini belirleyin. TypeScript’in moduleResolution ayarı; importların Node.js, bundler veya eski Node kurallarına göre nasıl aranacağını belirler. node16, nodenext ve bundler farklı çözümleme kuralları kullanır; bu nedenle yalnızca hata mesajını susturmak için rastgele bir değer seçmek doğru değildir.

Paket bulunamıyorsa kurulumu ve paket adını düzeltin​


Hata şu biçimdeyse paket adı bulunamıyordur:

Kod: 
import express from "express";
import { z } from "zod";

Projenin package.json dosyasının bulunduğu kök dizinde paketin gerçekten kurulu olduğunu kontrol edin:

Bash: 
npm install express zod
npm install -D @types/express
npx tsc --noEmit

Burada express ve zod çalışma zamanında kullanılan paketlerdir. @types/express ise TypeScript’in Express için tür bilgilerini bulmasına yarar. Her paket için ayrıca @types paketi gerekmez; paket kendi türlerini içeriyorsa ikinci bir paket kurmak gereksizdir. Paket adının npm’deki gerçek adıyla import satırındaki adın aynı olduğundan da emin olun.

Komutu başka bir klasörde çalıştırırsanız paket farklı bir node_modules dizinine kurulabilir. Bu nedenle önce çalışma dizinini, package.json dosyasının yerini ve kullanılan paket yöneticisini doğrulayın. npm install, pnpm install veya yarn install komutlarından birini, projede zaten kullanılan paket yöneticisinin kilit dosyasına göre kullanın; aynı projede paket yöneticilerini karıştırmak çözümleme sorunlarını artırabilir.

Kurulumdan sonra hata hâlâ görünüyorsa şu iki sonucu birbirinden ayırın:


Görülen durum | Anlamı | Sonraki işlem

node_modules içinde paket yok | Paket kurulmamış veya yanlış klasöre kurulmuş | Proje kökünde paketi kurun; package.json ve kilit dosyasını kontrol edin

Paket var, fakat türleri bulunamıyor | Paket tür bilgisi sağlamıyor veya tür paketi eksik | Paket belgelerine göre yerleşik tür desteğini ya da ilgili @types paketini kontrol edin

Paket var, alt yol bulunamıyor | Alt yol paket tarafından dışa aktarılmamış olabilir | Paketin desteklediği giriş noktasını kullanın; package.json içindeki exports kuralını inceleyin

TypeScript geçiyor, uygulama çalışırken hata veriyor | TypeScript ile çalışma zamanı aynı yolu çözümlemiyor | Bundler, Node.js veya çalışma komutunun alias ayarlarını TypeScript ile eşleştirin


Tablodaki son iki durum önemlidir: TypeScript’in importu tanıması, JavaScript çalışma zamanının aynı importu yükleyebildiğini tek başına kanıtlamaz.

Paket var ama alt modül bulunamıyorsa​


Şu import, paketin ana giriş noktası yerine belirli bir alt yolunu çağırır:

Kod: 
import helper from "some-package/internal/helper";

Paketin package.json dosyasında exports alanı varsa yalnızca açıkça dışa aktarılan yollar kullanılabilir. Node.js belgelerine göre exports alanı tanımlandığında paketin izin verilmeyen alt yollarına erişim engellenebilir; main alanı bulunsa bile exports önceliklidir.

Bu durumda yapılacak doğru işlem, paketin desteklediği herkese açık import yolunu kullanmaktır. Örneğin paket şu girişi yayımlıyorsa:

JSON: 
{
  "exports": {
    ".": "./dist/index.js",
    "./utils": "./dist/utils.js"
  }
}

some-package/internal/helper yerine yalnızca paketin yayımladığı some-package veya some-package/utils yolu kullanılabilir. node_modules içindeki dosyanın doğrudan yolunu import etmek geçici olarak çalışsa bile paket güncellendiğinde bozulabilir; bu, kalıcı çözüm değildir.

@/ veya başka bir alias kullanıyorsanız​


Şu tür importlar özel yol eşlemesi kullanır:

Kod: 
import Button from "@/components/Button";

TypeScript’in bu yolu anlayabilmesi için tsconfig.json içinde paths tanımlanabilir:

JSON: 
{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Bu ayar, @/components/Button yolunu TypeScript’in tür denetimi sırasında src/components/Button ile eşlemesine yardım eder. Ancak paths ayarı derlenmiş JavaScript içindeki import yolunu kendiliğinden değiştirmez. Bu nedenle bundler, test aracı veya Node.js çalıştırıcısı da aynı aliası tanımıyorsa derleme başarılı olsa bile uygulama çalışırken modül bulunamayabilir.

Alias kullanan projede şu sırayla ilerleyin:
  1. tsconfig.json dosyasının gerçekten derlemede kullanılan dosya olduğunu doğrulayın. Monorepo veya farklı scriptlerde başka bir yapılandırma dosyası seçiliyor olabilir.
  2. paths içindeki hedefin dosyanın gerçek konumuna göre yazıldığını kontrol edin. @/* için ./src/* kullanılıyorsa @/components/Button, src/components/Button konumunu arar.
  3. Bundler veya test aracındaki alias eşlemesini aynı hedefe ayarlayın.
  4. Uygulamayı TypeScript dosyasını doğrudan değil, projenin gerçek derleme/çalıştırma komutuyla başlatın.
  5. Hem npx tsc --noEmit hem de uygulamanın çalıştırma komutu başarılı oluyorsa çözümleme iki tarafta da eşleşmiş demektir.
Sadece TypeScript’in hatayı susturması için paths eklemek, çalışma zamanındaki sorunu çözmez. Sibling paketleri veya monorepo paketlerini elle aliaslamak yerine npm, Yarn ya da pnpm workspaces ile gerçek node_modules bağlantısı oluşturmak çoğu durumda daha tutarlıdır.

tsconfig.json ve modül sistemini eşleştirin​


Projeniz Node.js üzerinde çalışıyor ve package.json içinde ES modülü kullanıyorsa module, moduleResolution, dosya uzantıları ve package.json içindeki type alanı birlikte değerlendirilmelidir. Node.js, .mjs, .cjs ve package.json içindeki type değerine göre dosyaları farklı biçimlerde yorumlar.

Örneğin NodeNext kullanan bir projede temel yapılandırma şu biçimde olabilir:

JSON: 
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "rootDir": "src",
    "outDir": "dist",
    "strict": true
  },
  "include": ["src/**/*.ts"]
}

Bu örnek, her proje için otomatik olarak doğru yapılandırma değildir. Bundler kullanan bir uygulamada bundler çözümlemesi, Node.js’in doğrudan çalıştırdığı bir projede ise Node’un kullandığı modül düzeni daha uygun olabilir. Önemli olan tsconfig.json ayarının üretilen JavaScript’i çalıştıracak araçla aynı kuralları izlemesidir. TypeScript belgelerinde bundler çözümlemesinin göreli importlarda uzantı zorunluluğunu Node çözümleme modlarından farklı ele aldığı belirtilir.

TypeScript’in gerçekten hangi yolu aradığını görün​


Sorun görünürde doğruysa çözümleme izini açın:

Bash: 
npx tsc --noEmit --traceResolution

Çıktıda hata veren importun ardından TypeScript’in denediği yolları inceleyin. Örneğin src/utils/logger.ts yerine src/utils/Logger.ts aranıyorsa sorun dosya adının büyük-küçük harfidir. node_modules/some-package aranıyor fakat dizin yoksa paket kurulumunda sorun vardır. Paket bulunduğu hâlde package.json içindeki exports nedeniyle yol eleniyorsa desteklenmeyen bir alt yol kullanıyorsunuzdur.

İz çıktısının sonunda yalnızca “modül bulunamadı” yazması çözüm değildir; hata veren import satırına ait ilk başarısız aramayı bulun. Böylece dosya yolu, paket kurulumu, paths eşlemesi ve exports kısıtı arasında doğru ayrımı yapabilirsiniz. Değişiklikten sonra aynı komutu yeniden çalıştırın; yeni çıktıda TypeScript’in hedef dosyayı bulduğu görülmeli ve npx tsc --noEmit hata vermemelidir.

declare module ile hatayı gizlemeyin​


Şu tür bir bildirim bazı durumlarda TypeScript’in tür hatasını geçici olarak susturur:

Kod: 
declare module "some-package";

Fakat bu satır paketi kurmaz, yanlış import yolunu düzeltmez ve çalışma zamanında modülü yüklemez. Yalnızca modülün türlerini any benzeri belirsiz bir biçimde kabul ettirebilir. Paket gerçekten mevcut değilse veya bundler yolu çözemiyorsa uygulama yine çalışmaz. Bu nedenle önce gerçek dosya/paket çözümünü düzeltin; bildirim dosyasını ancak türleri olmayan ve çalışma zamanında gerçekten var olan özel bir modül için, bilinçli bir geçici bildirim olarak kullanın.

Düzeltmeden sonra sonucu nasıl doğrulamalısınız?​


Şu sırayı izlemek, derleme ile çalışma zamanı sorunlarını birbirine karıştırmanızı önler:
  1. Dosya importuysa yolu ve dosya adını düzeltin; paket importuysa paketin proje kökünde kurulu olduğunu doğrulayın.
  2. Alias kullanıyorsanız tsconfig.json, bundler ve test aracındaki eşlemeleri aynı hedefte birleştirin.
  3. Node.js veya bundler projesine uygun module ve moduleResolution değerlerini kullanın.
  4. npx tsc --noEmit komutunu çalıştırın. Hata yoksa TypeScript çözümlemesi başarılıdır.
  5. Uygulamayı gerçek çalıştırma komutuyla başlatın. Burada hata oluşuyorsa sorun artık TypeScript tür çözümlemesinden çok çalışma zamanı, bundler, exports veya üretilen JavaScript yolundadır.
  6. Hata devam ederse npx tsc --noEmit --traceResolution çıktısında hata veren importun denenen yollarını inceleyin.
tsc başarılı olduğu hâlde uygulama başarısızsa TypeScript’in modülü bulduğunu, fakat çalışma ortamının aynı importu bulamadığını anlarsınız. tsc de başarısızsa önce TypeScript yapılandırması, dosya konumu, paket kurulumu veya paket giriş noktası düzeltilmelidir.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
  • Bing
Toplam: 2 (Üye: 0, misafir: 0, robot: 2)