@adidahiya Lihat komentar ini oleh @nchen63.

Dari @nchen63 :

Ini memperbaiki tab -> x spasi dan x spasi -> tab, tetapi tidak memperbaiki x spasi -> y spasi

Itu HARUS melakukan x spaces ke y spaces sekalipun.

Proyek saya menggunakan 2 dan 4 spasi. Memperbaiki aturan x spaces menjadi y spaces akan sangat berguna.

Saya juga mengalami masalah ini mengharapkannya untuk memperbaiki pelanggaran ukuran, atau setidaknya melaporkannya sebagai kesalahan sehingga saya dapat memperbaikinya. Saat ini tampaknya konfigurasi untuk ukuran indentasi yang didokumentasikan di situs (https://palantir.github.io/tslint/rules/indent/) sebenarnya tidak melakukan apa-apa.

Ya, tolong perbaiki bug ini. Angular CLI menggunakan 2 spasi untuk level indentasi saat membuat file atau proyek, dan semua tanda kutip adalah tanda kutip tunggal. Kemudian menjalankan tslint untuk memperbaikinya sesuai dengan tslint.json pengguna. Kutipan berfungsi dengan baik (berubah menjadi tanda kutip ganda sesuai preferensi saya), tetapi lekukan tetap di 2 spasi (sementara saya lebih suka 4). Tslint hanya melaporkan kesalahan jika melihat karakter TAB yang sebenarnya, tetapi tampaknya masuk akal bahwa ia juga harus memeriksa jumlah spasi

Sepertinya saya seperti implementasi yang digunakan di https://github.com/palantir/tslint/blob/master/src/rules/indentRule.ts cukup naif, dan saya tidak berharap itu berfungsi untuk x spaces -> y spaces . Pendekatannya tampaknya baik-baik saja dengan tab, berdasarkan komentar di sini, tetapi saya tidak dapat melihat pendekatan ini layak untuk spasi.

Katakanlah, misalnya, lebar lekukan 2 spasi dipilih, dan pertimbangkan kode ini:

foo = {
    a: {
  b: {
    c: 'c'
  }
    },
    d: 'd'
}

Bagaimana implementasi kami saat ini mengetahui kegagalan ini sama sekali? Setiap urutan spasi melewati regex / / . Bahkan jika kami mencari kelipatan 2 spasi, ini akan berlalu. Demikian pula, dalam skenario lekukan multi-level, 4 spasi awal bisa menjadi skenario yang lewat, sedangkan memulai satu level lekukan dengan 4 spasi harus gagal.

Saya pikir solusi apa pun perlu melintasi AST, mirip dengan apa yang dilakukan eslint (https://github.com/eslint/eslint/blob/master/lib/rules/indent.js). Kelemahan dari itu adalah bahwa kami akan menerima sedikit peningkatan kinerja untuk tabs -> spaces atau spaces -> tabs . Kita bisa menyiasatinya dengan memilih implementasi berdasarkan pengaturan, tetapi saya mengantisipasi bahwa implementasi saat ini akan gagal jika kombinasi tab dan spasi digunakan, dalam hal ini kita hanya boleh menggunakan solusi berbasis AST.

Saya pikir setidaknya beberapa pekerjaan AST yang dilakukan dalam implementasi eslint dapat ditangani oleh perpustakaan TypeScript secara langsung, jadi solusinya tidak boleh terlalu sulit untuk ditulis.

Bagaimana implementasi kami saat ini mengetahui kegagalan ini sama sekali?

Tidak _secara teknis_ perlu. Aturan align akan mencegah Anda menulis kode seperti itu. Tentu, kita bisa menjalankan AST dalam aturan indent juga. Yang saya pedulikan adalah bahwa beberapa kombinasi indent dan align memungkinkan saya untuk mencapai apa yang saya tulis dalam deskripsi masalah.

Aturan align akan mencegah Anda menulis kode seperti itu.

Bagus! Saya melewatkan itu ketika saya memeriksa kode sumber. Aku akan mengambil puncak di sana juga. TBH, saya agak suka ide memanfaatkan aturan yang ada untuk membuat orang lain naif mungkin.

Saya mengalami masalah yang sama. Aturan di bawah ini akan menangkap tab yang digunakan sebagai ganti spasi, tetapi tidak akan menangkap jumlah spasi yang salah. Saya dapat mengubah 2 ke nomor lain, dan saya masih tidak mendapatkan kesalahan. Saya menggunakan tslint 5.5.0.

"indent": [true, "spaces", 2],

Ada pembaruan tentang ini? (Jika seseorang belum mengerjakan perbaikan, saya bersedia mencobanya.)

@mDibyo lakukanlah

@mDibyo Sudahkah Anda membuat kemajuan dalam hal ini?

Saya memiliki implementasi parsial. Akan mencoba menyelesaikannya dan memasang PR selama akhir pekan

Hanya ingin memberi tahu bahwa masalah ini telah menjadi prioritas yang lebih rendah bagi saya sejak saya mulai menggunakan pemformatan yang lebih cantik dengan tslint-plugin-prettier untuk proyek saya. Kami mungkin mencoba menambahkan lebih banyak dukungan resmi untuk lebih cantik di konfigurasi bawaan di masa mendatang dan menyesuaikan fokus dengan aturan inti yang tidak terkait dengan pemformatan.

Lebih cantik, di sisi lain, berusaha untuk memasukkan sebagian besar kode ke dalam setiap baris.

Bagaimana jika Anda tidak menginginkan itu?

Dengan lebar cetak yang disetel ke 120, yang lebih cantik dapat menghasilkan kode yang terlalu padat, atau kode yang tidak diinginkan.

Kami menggunakan 120 karakter dalam proyek kami.

Juga, itu adalah ketergantungan lain. Saya pikir saya lebih suka menggunakan aturan TSLint biasa.

Saya pikir saya lebih suka menggunakan aturan TSLint biasa.

@glen-84 ya, tidak apa-apa, itulah sebabnya saya tidak mengatakan kita harus menghapus semua aturan pemformatan dari TSLint dan mendelegasikan sepenuhnya ke formatter eksternal. Lebih cantik jelas berpendirian dan tidak semua orang akan memilih untuk menggunakannya. Masalah ini masih terbuka untuk PR.

apa yang terjadi dengan masalah ini?

PR saya sedang berjalan, untuk banyak kasus, masih membutuhkan waktu. @cyberhck

jadi kami berharap itu segera digabungkan :slightly_smiling_face:

Ada pembaruan di sini?

Mungkin kita bisa meminta pengelola format-typescript untuk mengekspos beberapa API? Paket sudah dapat memverifikasi bahwa seluruh file sumber diformat sesuai dengan pengaturan dalam file tslint.json

Namun, mungkin perlu bantuan untuk bermain bagus dengan pengaturan fixer TSLint.

Masalahnya tampaknya bahwa kegagalan hanya dilaporkan jika menggunakan karakter spasi yang salah, bukan jika ukuran indentasi tidak aktif.

@adidahiya Saya tidak bisa melaporkan kesalahan jika karakter lekukan yang salah digunakan. Jika saya menetapkan aturan ke spasi/4 dan memiliki sesuatu seperti:

export function foo() {
return 123;
}

atau

export function foo() {
<tab>return 123;
}

Itu tidak melaporkan kembali kesalahan. Per komentar asli Anda, apakah Anda yakin itu melaporkannya jika itu karakter spasi yang salah?

Ada kemajuan dalam hal ini? Hanya bertanya

Nasihat? Gunakan Lebih Cantik .

Adakah yang sudah mencoba tslint-eslint-rules ?

@jscharett tslint-eslint-rules bekerja dengan aturan ter-indent . Sayangnya itu tidak menutupi lekukan JSX ...

Adakah harapan untuk perbaikan di sini?

Bug ini masih belum diperbaiki di v5.10.0

Saya harus mengatakan, saya tidak membayangkan TSLint akan dapat memformat kode JS sebaik Prettier. Ini adalah masalah yang rumit, dan Prettier telah menyelesaikannya lebih baik daripada orang lain. Saya tidak berpikir kita harus mengandalkan TSLint untuk ini, terutama karena proyek sering menggunakan kedua alat secara bersamaan, dan konflik kemungkinan akan muncul...

EDIT: Untuk gagasan yang lebih baik tentang _bagaimana_ rumitnya masalah ini, tinjau PR ini , atau lihat kode sumber yang Lebih Cantik. Jika demonstrasi ini tidak menurut Anda "rumit", tolong bantu proyek ini dengan PR !

@aervin saya cenderung tidak setuju di sini. Kedua proyek tersebut menurut saya memiliki tujuan yang berbeda. Lebih cantik termasuk dalam kategori pemformatan sementara TSLint lebih sesuai dengan validasi. Ya, TSLint dapat melakukan pemformatan untuk beberapa aturan, tetapi tujuan yang dimaksudkan sebagai linter, kembali ke validasi.

Masalah dengan mengandalkan Prettier adalah bahwa hal itu berpendirian. Itu bagus jika Anda setuju dengan gayanya, tetapi bagaimana jika Anda tidak? Kami dulu semua menggunakan JSLint, dan kami semua mengeluh karena sangat berpendirian. Kemudian datang JSHint dan JSCS, yang memberi kami kendali. Sekarang kami memiliki alat canggih seperti @eslint yang memberi kami kemampuan untuk plug-n-play dan "memperbaiki" masalah secara otomatis.

Meskipun saya yakin Prettier adalah proyek yang hebat, saya pribadi melihatnya sebagai langkah mundur. Itu mengambil kendali dariku. TSLint tidak perlu "memperbaiki" kode, jika itu masalahnya, tandai saja sebagai masalah. Saya tidak ragu bahwa masalah ini rumit, tetapi eslint menyelesaikannya. Aturan yang digunakan untuk bekerja; apa yang berubah untuk memecahkannya?

@jscharett Terima kasih atas tanggapan Anda yang menyenangkan. Saya setuju bahwa proyek-proyek ini memiliki tujuan yang berbeda, atau _harus_ miliki. Argumen saya adalah bahwa kita harus membatasi proyek-proyek ini untuk tujuan-tujuan itu. Mari serahkan Prettier untuk memperbaiki masalah lekukan, dan biarkan TSLint memperingatkan pengembang tentang fungsi panah yang dapat disederhanakan.

Saya juga setuju bahwa Prettier berpendirian. Saya lebih suka itu tentang Pretty. Sekarang tim saya tidak perlu membahas pendapat pemformatan siapa yang lebih masuk akal. Kita semua bisa mengeluh tentang Prettier :laughing: .

EDIT:

Aturan yang digunakan untuk bekerja; apa yang berubah untuk memecahkannya?

Komentar masalah pembukaan membuat saya percaya bahwa aturan ini tidak pernah berfungsi sebagaimana dimaksud.

Meskipun saya yakin Prettier adalah proyek yang hebat, saya pribadi melihatnya sebagai langkah mundur. Itu mengambil kendali dariku.

Pengalaman saya adalah bahwa saya pikir saya peduli untuk memiliki kontrol halus atas aturan pemformatan sampai saya menambahkan Lebih Cantik... mereka diformat secara konsisten. Ini adalah beban kognitif yang sangat besar untuk tidak khawatir tentang itu lagi, dan berkonsentrasi sepenuhnya pada apa yang saya ingin kode untuk _do_ daripada tampilannya.

tslint sudah memvalidasi hal-hal lain yang termasuk dalam kategori pemformatan. Misalnya, menegakkan perataan, gaya braket, atau spasi antara nama variabel dan operator. Selain itu, diinginkan untuk dapat memvalidasi lekukan tanpa harus bergantung pada solusi berpendirian seperti lebih cantik.

Perlu lebih sedikit diskusi, dan lebih banyak PR. 😉😉

lanjutkan @ffxsam

Komentar saya kebanyakan lidah-di-pipi. Meskipun saya bertanya-tanya mengapa masalah ini sudah lebih dari satu tahun dan tidak ada kemajuan. Sepertinya semua orang hanya berdebat tentang linting vs Prettier.

@ffxsam Karena ada perdebatan tentang apakah tslint lebih banyak tentang bagian ts atau tentang bagian lint

Itu poin yang valid. Sepertinya ada beberapa tumpang tindih dengan TSLint/ESLint. Tetapi faktanya tetap ada opsi indent yang tidak berfungsi yang telah rusak untuk siapa yang tahu berapa lama. Sepertinya hal tercepat/termudah bagi seseorang yang akrab dengan basis kode TSLint untuk memperbaikinya ...?

Berikan suara untuk memperbaiki x spaces => y spaces . Ini adalah fitur yang sangat diandalkan oleh perusahaan kami. Tidak masuk akal hanya tidak memperbaiki ini.

@ffxsam Saya menonton masalah ini selama hampir satu tahun sekarang, ya sudah lama, tetapi seperti yang Anda lihat ada dua upaya PR, dan itu tidak berhasil sampai sekarang, saya pikir ini lebih sulit daripada yang terlihat, tetapi dari tentu saja untuk pengelola mungkin lebih mudah, saya hanya punya banyak kesabaran :slightly_smiling_face:

Masih dapat direproduksi dalam proyek kosong
https://github.com/dimaShin/tslint-reproduce-2814

Hai @dimaShin , terima kasih telah meluangkan waktu untuk membuat repositori yang dapat direproduksi. Namun tim sudah mengetahui masalah ini, reproduksi tidak pernah menjadi masalah.

Kami hanya menunggu fitur ini, mungkin dengan opsi perbaikan, tapi itu bukan masalah bagi saya. Terakhir kali saya memeriksa orang-orang menggunakan lebih cantik untuk memeriksa lekukan dan tslint untuk yang lainnya.

Saya tidak mengatakan itu akan cocok untuk Anda, bagi saya itu pasti tidak, saya juga menyarankan menggunakan .editorconfig untuk opsi khusus ini dan beralih ke tslint nanti ketika ini diselesaikan.

Sekali lagi, terima kasih telah meluangkan waktu untuk menambahkan lebih banyak info :)

Mari kita tentukan strategi untuk memeriksa lekukan. Untuk referensi, berikut adalah strategi yang digunakan oleh eslint:

1. Instance OffsetStorage menyimpan peta offset yang diinginkan, di mana setiap token memiliki offset tertentu dari token tertentu lainnya atau ke kolom pertama.
2. Saat AST dilintasi, modifikasi offset token yang diinginkan. Misalnya, saat memasukkan BlockStatement, offset semua token di BlockStatement dengan 1 level indentasi dari kurung kurawal pembuka BlockStatement.
3. Setelah melintasi AST, hitung tingkat indentasi yang diharapkan dari setiap token sesuai dengan wadah OffsetStorage.
4. Untuk setiap baris, bandingkan lekukan yang diharapkan dari token pertama dengan lekukan sebenarnya dalam file, dan laporkan token jika kedua nilai tidak sama.

Strategi ini didasarkan pada sintaks, yang, berdasarkan komentar sebelumnya, terlalu keras kepala karena membutuhkan garis untuk diputus dengan cara tertentu. Saya mengusulkan cara sederhana untuk memeriksa lekukan yang tidak tergantung pada bagaimana kode dipecah menjadi beberapa baris:

1. Unit lekukan ditentukan dalam pengaturan. Untuk tab, itu adalah satu karakter tab. Untuk spasi, terdiri dari dua atau empat karakter spasi.
2. Baris pertama file yang tidak kosong harus memiliki nol unit lekukan
3. Setiap baris non-kosong berikutnya harus memiliki
   Sebuah. Jumlah unit lekukan yang sama dengan baris tidak kosong sebelumnya atau
   B. Kurang dari jumlah unit lekukan sebagai baris tidak kosong sebelumnya atau
   C. Tepat satu lebih banyak dari jumlah unit lekukan sebagai baris tidak kosong sebelumnya

Beberapa hal tambahan untuk didiskusikan:

• Parameter ukuran tidak berpengaruh dengan tab (mengapa?)
• Tidak ada alasan parameter ukuran tidak boleh berupa bilangan bulat positif
• Memperbaiki ukuran lekukan secara otomatis mungkin tidak dapat diimplementasikan tanpa melalui rute strategi sintaksis

@stifflerus Aturan juga harus bekerja dengan fungsi if/for/arrow tanpa blok {}

@maximelkin Apakah contoh yang Anda berikan tidak menjorok ke baris kedua? Bisakah Anda memberikan contoh di mana strategi yang diusulkan akan gagal?

if(this) that(); //okay because it's all one line

if(this)
  that(); //also okay because the second line is indented

let x = () => f(); //okay because it's all one line

let y = () =>
  f(); // I have not seen any code but like this but it would be okay

Akan luar biasa jika ini diperbaiki.

Saya tidak percaya sesuatu yang mendasar seperti menegakkan aturan lekukan masih tidak berfungsi.

Jadi, tidak ada cara untuk membuat kode ts seperti itu pada tahun 2018?

const x = {
  a: 1,
   b: 2,
}

Bekerja untuk saya
./.eslintrc.ts.js :

module.exports = {
  'parser': 'typescript-eslint-parser',
  'parserOptions': {
    'ecmaVersion': 6,
    'sourceType': 'module',
    'ecmaFeatures': {
      'jsx': true,
    }
  },
  'plugins': [
    'react',
  ],
  'rules': {
    'indent': ['error', 2],
  },
}

yarn eslint --no-eslintrc --config ./.eslintrc.ts.js --ext .tsx src

https://github.com/eslint/typescript-eslint-parser

solusi yang saya temukan untuk masalah indentasi di sudut adalah menambahkan lebih cantik dengan langkah-langkah selanjutnya:
npm install --save-dev tslint-plugin-lebih cantik lebih cantik tslint-jasmine-rules
edit tslint.json -->
` "rulesDirectory": [
"node_modules/codelyzer",
"node_modules/tslint-plugin-cantik",
"node_modules/tslint-jasmine-rules/dist"

],
"extends": "tslint-plugin-cantik",

"aturan": {
"lebih cantik": benar,
//tambahkan di sini aturan yang Anda inginkan`

dan di package.json tambahkan -->
" ,"lebih cantik": {
"singleQuote": benar,
"lebar cetak": 140,
"setengah": benar,
"bracketSpacing": benar,
"arrowParens": "selalu",
"parser": "ketik"
}"

Ini adalah fungsi yang hampir semua orang gunakan setiap hari. Akan sangat menghargai jika masalah ini mendapat perhatian lebih.

Teman-teman, Anda dapat menggunakan opsi ter-indent yang disediakan oleh tslint-eslint-rules.

"ter-indent": [ benar, 4, { "SwitchCase": 1 }]

Itu berhasil untuk saya. Bersulang!

@hiteshaleriya itulah yang saya miliki di proyek saya untuk sementara waktu sekarang, tetapi itu tidak benar-benar memperbaiki kesalahan, hanya membungkamnya ... inilah tslint.json :

{
    "extends": "tslint-config-airbnb",
    "rules": {
        "ter-indent": ["error", "spaces", 4],
        "no-unused-vars": ["warn"],
        "no-multi-spaces": false,
        "no-console": false,
        "max-line-length": false,
        "import-name": false
    }
}

dan inilah contoh relevan yang selesai tanpa menyebabkan peringatan atau kesalahan:

function retrieveAndSetConfig(): Promise<any> {
  return new Promise((resolve, _) => {
  // ^ 2 spaces, expected 4
    const ghe = new GHEUtils();
    // ^ 4 spaces, expected 8
    // ...
}

Itu juga tidak menunjukkan kesalahan saat tab digunakan (walaupun itu mungkin karena desain ketika ada 4 spasi?).

@SpencerKaiser Bisakah Anda memperbarui aturan ter-indent Anda seperti yang ditunjukkan di bawah ini dan kemudian coba:

"ter-indent": [true, 4]

Saya mencoba contoh Anda dan itu berfungsi seperti yang diharapkan di akhir saya (menyebabkan kesalahan).

@hiteshaleriya terima kasih telah --fix . Ada ide?

@SpencerKaiser Bisakah Anda mencoba menjalankan perintah --fix dua kali. Pertama kali akan membuat indentasi baris pertama saja kemudian kedua kalinya akan mengindentasi sisanya (untuk kode contoh Anda). Kelihatannya aneh tapi tolong laporkan masalahnya jika tidak berhasil.

@hiteshaleriya jadi beberapa pengamatan... Saya tidak perlu menjalankannya lagi, saya perlu menjalankannya kira-kira n/4 kali di mana n adalah panjang lekukan dalam spasi garis indentasi terjauh dalam proyek \_(ツ)_/¯

Setelah akhirnya menyelesaikan semuanya, sepertinya melewatkan kesalahan lekukan dasar seperti ini:

class Something {
    function myFunc() {
        const myThing = {
            wat: 1,
         wattt: 5,    // 9 spaces, expected 12
        };
    }
}

Jika saya mengacaukan level indentasi dari const (baris 17) ke 0 spasi, sisanya ditandai dengan kesalahan _mengecualikan_ baris dengan spasi saat saya tinggalkan --fix :

ERROR: 17:1  ter-indent  Expected indentation of 8 spaces but found 0.
ERROR: 18:1  ter-indent  Expected indentation of 4 spaces but found 12.
ERROR: 20:1  ter-indent  Expected indentation of 0 spaces but found 8.

Dengan --fix , inilah pass pertama:

        const myThing = {
    wat: 1,
         wattt: 5,
};

Dan umpan kedua:

        const myThing = {
            wat: 1,
         wattt: 5,
        };

Pikiran??

Bagaimana saya memecahkan masalah itu dengan tslint-config-prettier

@shubich akhirnya saya melakukan hal yang sama...

Apakah ada pembaruan tentang ini?

@MaKCbIMKo sejauh yang saya mengerti, seluruh tim akan bergerak untuk mengintegrasikan eslint visit TypeScript-eslint, dan dalam waktu dekat tslint akan ditinggalkan, jadi lebih baik mengabaikan aturan ini untuk saat ini (atau gunakan tslint-config-prettier )

Penutupan karena kerumitan tugas ini dan perubahan arah proyek: #4534

Aturan ESLint dari TypeScript-eslint berfungsi dengan baik untuk saya (lihat #4534):

module.exports = {
    "env": {
        "browser": true,
    },
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2019,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        },
        "project": "./tsconfig.json",
    },
    "plugins": ["@typescript-eslint"],
    "rules": {
        "@typescript-eslint/indent": ["error", 2] // or ["error", "tab"]
    }
}

Bagaimana saya memecahkan masalah itu dengan tslint-config-prettier

Tautan tidak ditemukan.

Bunyi bip! TSLint sudah usang dan Anda harus beralih ke TypeScript-eslint ! 🤖

Masalah ini sedang dikunci untuk mencegah diskusi lebih lanjut yang tidak perlu. Terima kasih! 👋

PS tslint-config-prettier - harap berhenti menggunakan _linters_ seperti TSLint untuk _format_ TypeScript Anda. Itu lebih baik dilakukan oleh _formatter_ seperti Prettier .