javascript - Yalnızca terminali kullanarak bir JS dosyası açıldığında VSCode'un gösterdiği sorunlar listesini nasıl çıktılarım?

VSCode'un bana hata ve uyarıları göstermek için kullandığı varsayılan jsconfig.json veya tslint.json nedir?

JavaScript projemdeki tüm problemleri görmek istiyorum. jsconfig.json veya tsconfig.json dosyalarım yok. Sadece bazı dosyalarda //@ts-check kullanıyorum.

Her dosya js dosyası açtığımda, sorunlar panelinde bir uyarı listesi görüyorum. Projedeki tüm dosyalardaki sorunları almak istiyorum. Sadece açılmış dosyalar değil. VS Studio bunu desteklemiyor, bu yüzden bunu CLI üzerinden yapmayı arıyorum.

Bu listeyi bir CLI kullanarak almak istiyorum. Böylece bu, CI sürecinin bir parçası olabilir. Kendi tsconfig.json ve tslint.json dosyalarımla tslint ve typescript CLI kullanmayı denedim ama VSCode'un bana gösterdiğiyle tam olarak aynı sorunları ve uyarıları hiç alamadım. Bence VSCode, bilgileri göstermek için varsayılan bir tsconfig ve tslint kullanıyor.

Bunu TypeScript dil sunucusunun GitHub'ında ve VSCode deposunda bulamadım.

Başka bir deyişle: Terminalden başlatabileceğim ve aynı dosyayı vscode'da açarsam vscode'nun bana göstereceği tüm problemleri listelenecek bir komut arıyorum.

tsconfig veya jsconfig dosyaları olmadan bir terminal kullanarak bu çıktıyı nasıl alırım.

Cevap #1

//@ts-check tarafından oluşturulacak hataları görmek için, --noEmit ve --allowJs bayrakları ile TypeScript derleyicisini (tsc) kullanabilirsiniz:

npm install -g typescript
tsc --noEmit --allowJs fileToCheck.js

noEmit, kod üretilmeyeceği ama hataların yine de görüntüleneceği anlamına gelir.

Projenizdeki her dosya için bunu çalıştırmak için en iyi yaklaşım, projenizi ve temel ayarları tanımlayan çok basit bir jsconfig.json dosyasını çalışma alanınızın kökünde oluşturmaktır. Bu dosyaların nasıl oluşturulacağına dair belgelerde daha fazla ayrıntı vardır, ancak işte başlangıç için bir jsconfig.json:

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es2016",
        "jsx": "preserve"
    },
    "exclude": [
        "node_modules",
        "**/node_modules/*"
    ]
}

Sonra çalıştır:

tsc --noEmit -p jsconfig.json

Alternatif olarak, bir jsconfig.json oluşturmak istemiyorsanız, find kullanarak çalışma alanınızdaki her js dosyasıyla tsc çalıştırmayı deneyebilirsiniz:

tsc --noEmit --allowJs `find . ! -path '*/node_modules/*' -name "*.js"`

Yukarıdakiler, TypeScript'in kendisinden kaynaklanan hataları ele alır. Ancak VS Code, tek bir dosyada typescript, tslint ve bir kod yazım denetleyicisi gibi birden fazla kaynaktan gelen hataları gösterebilir. Bunu komut satırından elde etmenin genel bir yolu yoktur.

TSLint ve eslint gibi araçlar, kullanabileceğiniz kendi CLI'larını sağlar. Bu, geliştiricilerin istedikleri editörü kullanabilmesi anlamına geldiği için çoğu açık kaynak proje tarafından doğrulama için kullanılır. Örneğin, sürekli entegrasyon skriptiniz tsc --noEmit -p jsconfig.json && eslint ... && ... komutunu çalıştırır.

Ancak eğer gerçekten, gerçekten VS Code'un editörde gösterdiği aynı hataları almak istiyorsanız, vscode-test'e benzer bir yaklaşımı kullanarak bir VS Code örneğini kontrol eden bir betik çalıştırabileceğinizi düşünüyorum. Hataları almak için kullanmak isteyeceğiniz VS Code API'si getDiagnostics(resource: Uri)

Cevap #2

Sağladığınız ekran görüntüsü, yerleşik TypeScript'i kullandığınızı gösteriyor ve vscode ile birlikte gelir, ts(<code>) kısaltmasıyla çıktılar.

Bence, (yüzde 100 emin değilim) o Yerleşik TypeScript'in konfigürasyonu, ayarları açıp şunu aradığınızda göreceğiniz birçok yapılandırma seçeneğinden oluşuyor: "typescript" veya sol taraftaki ağaç menüsünde "Extensions > TypeScript" bölümünü genişletmek. Bence, yine: emin değilim, yapılandırmaların çalışma zamanında toplanıp derlendiğini, hiçbir zaman yakalayabileceğiniz bir dosyaya çıktı vermediğini düşünüyorum...

Yine de, olağan iş akışı resmi tslint uzantısını almak:
https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-tslint-plugin
Bu, yerleşik olandan farklıdır ve temel bir tslint.js dosyası almak, takımınızın tercihine uygun olacak şekilde, her bir projenizde tekrar kullanabileceğiniz şekilde, daha sonra tsc ... komutu CI sürecinizin bir parçası olacak ve projenin tslint.js yapılandırma dosyasını tüketecektir.

Yeni uzantı ayrıca sorunları sorunlar bölümüne de aktaracaktır (çıkış tslint(<code>))

Tam olarak ne demek istediğini anlayamamış olabilirim ama sanırım doğru cevap bu.

İlgili makaleler