butuh ini loh

Kasus penggunaan saat ini untuk fitur ini adalah pengujian unit yang berhubungan dengan spasi putih. Kami memiliki aturan "no-trailing-whitespace" yang diaktifkan di basis kode kami untuk alasan yang baik, tetapi tidak dapat mengalahkannya pada tingkat blok berarti bahwa kami tidak dapat dengan mudah menguji spasi spasi dan carriage return yang tertinggal menggunakan string template ES6 .

salah satu kasus penggunaan saya untuk menggunakan bundling khusus _ a.k.a partial import _ di mathjs

// tslint:disable:no-var-requires
import core from 'mathjs/core'

// @ts-ignore
import mathUnit from 'mathjs/lib/type/unit'
// @ts-ignore
import mathExpression from 'mathjs/lib/expression/function'
// @ts-ignore
import mathArithmatic from 'mathjs/lib/function/arithmetic'


const math = core.create()
// math.import(require('mathjs/lib/type/unit'))
// math.import(require('mathjs/lib/expression/function')) // compile, eval
// math.import(require('mathjs/lib/function/arithmetic')) // basic arithmetic like divide, exponent, etc

math.import(mathUnit)
math.import(mathExpression) // compile, eval
math.import(mathArithmatic) // basic arithmetic like divide, exponent, etc

export const unit = math.unit
export const createUnit = math.createUnit
export const compile = math.compile

Saya ingin mengabaikan kesalahan untuk seluruh file. Saya telah mewarisi beberapa kode JS ES6 yang ingin saya transpile ke ES5 tetapi harus menggunakan Babel saat ini. Akan lebih baik untuk mengganti nama file menjadi .ts dan transpile dengan TS.

@ptallett Anda bisa mengkompilasi file .js menggunakan allowJs dan memasukkannya ke dalam kompilasi. Secara default, kami tidak mengeluarkan kesalahan pada file .js kecuali file tersebut memiliki // @ts-check komentar di bagian atas, atau Anda mengaktifkan checkJs .

Saya masih menyukai fungsi ini, saya sedang duduk di file uji, ini memiliki ekstensi .ts, jadi saya dapat mengimpor dan dengan mudah melihat parameter apa yang pergi ke mana, dan mengompilasinya ke direktori di samping file src sangat brilian untuk kasus penggunaan saya .

Sebagian besar baris saya sekarang berwarna merah, karena saya sengaja mencoba untuk mengecualikan beberapa parameter, atau memberikan jenis fungsi yang berbeda, daripada yang diperlukan semula, dan mengharapkan kesalahan yang dilemparkan, karena saya juga memeriksanya saat runtime.

Akan menyenangkan untuk tidak memiliki banyak garis merah di mana-mana. :)

Apakah ada pembaruan tentang itu, atau adakah yang menemukan cara yang baik untuk melakukan ini?

Menggunakan lodash & terutama lodash/fp dengan TypeScript sangat menyakitkan, dan bahkan dengan versi terbaru lodash & @types/lodash Anda dapat berakhir dengan pesan kesalahan yang sangat samar.

Jika kita dapat memiliki @ts-ignore-block yang mengabaikan kesalahan untuk blok berikut, akan sangat bagus untuk kasus penggunaan seperti ini di mana _Anda tahu apa yang Anda lakukan_ :-)

Saya bekerja dengan kode lama dengan banyak variabel cakupan global, dan menulis @ts-ignore di setiap baris menjadi membosankan, ada pembaruan tentang ini?

Juga mencari pembaruan tentang permintaan ini. Terima kasih!

Ini juga akan sangat penting untuk apa yang saya lakukan (yaitu memeriksa jenis fungsi render template Vue yang dihasilkan, yang akan memerlukan penonaktifan pemeriksaan khusus untuk blok kode.)
Bersamaan dengan masalah ini, #19139 akan menjadi sangat penting, karena terutama saat menerapkan sebagian besar kode, Anda hanya ingin menonaktifkan pemeriksaan tertentu.

dengan menekan file lubang ini dapat ditambahkan ke Editor seperti kode vs untuk disimpan di pengaturan ruang kerja atau semacamnya.

Juga membutuhkan ini. Saya membuat seluruh file ts secara otomatis dengan tipe untuk skema GraphQL saya menggunakan graphql-code-generator dan ada impor asing yang memicu noUnusedLocals.

/* tslint:nonaktifkan */

kode

/* tslint:aktifkan */

// @ts-ignore-start
// @ts-ignore-end

Dapat digabungkan dengan: https://github.com/Microsoft/TypeScript/issues/19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn ini bukan tslint.

Kadang-kadang ketika saya sedang memindahkan barang-barang dan refactoring, saya ingin untuk sementara mengabaikan seluruh file (yaitu tidak mengkompilasinya), tanpa mengutak-atik opsi CLI.

Yang tercepat/termudah adalah flag di bagian atas file:

// @ts-ignore-file

@lonix1 Anda menggunakan kasing dicakup oleh:

// @ts-ignore-start
// @ts-ignore-end

Anda tidak harus menggunakan bagian // @ts-ignore-end . Banyak alat serat bekerja seperti itu.

@mgol Saya tidak ingin menggagalkan utas ini ... tapi saya mencoba saran Anda - terima kasih! - dan itu tidak berhasil untuk saya. Saya menyatukan garis di bagian atas file, dan juga mencoba satu di bagian atas dan yang lainnya di bagian bawah.
Adakah yang bisa membuatnya bekerja?

@lonix1 Maksud saya proposal @Blanen juga akan bekerja untuk Anda, kami tidak perlu TypeScript untuk mengimplementasikan // @ts-ignore-start + // @ts-ignore-end dan // @ts-ignore-file , mengimplementasikan // @ts-ignore-start + // @ts-ignore-end sudah cukup. Ini tidak dilaksanakan, itu sebabnya masalah ini masih terbuka.

@DanielRosenwasser ini hanya akan berfungsi ketika file ts disimpan di folder lain selama pembuatan. ketika proyek diatur untuk menempatkan file js di sebelah file ts itu tidak akan. Juga apakah file js akan 'dikompilasi' misalnya berubah menjadi es5 ? Saat mengangkut kode lama, ini akan sangat membantu.

Butuh fitur ini.

Kasus penggunaan:

TypeORM mengharapkan kita untuk membuat kelas entitas DB yang memiliki kolom yang mungkin atau mungkin tidak dapat dibatalkan. Banyak kolom (karenanya) tidak dapat dibatalkan…dan karenanya harus diperlakukan, kecuali dalam definisi kelas, seolah-olah properti adalah tipe yang ditentukan tanpa syarat. Namun, TypeScript mengharuskan kita untuk mendefinisikan setiap kolom sebagai sangat diketik. Oleh karena itu, kami berakhir dengan banyak entitas seperti:

@Entity('investigation')
export class InvestigationEntity {
    @PrimaryGeneratedColumn('uuid')
    // @ts-ignore TS2564
    public investigationId: string;

    @Column({ type: 'uuid' })
    // @ts-ignore TS2564
    public userId: string;

    @Column({ type: 'jsonb' })
    // @ts-ignore TS2564
    public metadata: IEncryptedJSONContainer;
}

Setiap kolom diperlukan dan (karenanya) pasti berisi nilai, tetapi karena cara kerja TypeORM, setiap properti harus didefinisikan sedemikian rupa sehingga tidak memiliki penginisialisasi. Akan sangat nyaman untuk dapat menekan masalah khusus yang diturunkan dari ORM/khusus ini, untuk seluruh kelas (karenanya/atau file).

@haggholm ada alasan untuk memilih ts-ignore daripada public metadata!: IEncryptedJSONContainer ?

@RyanCavanaugh Ketidaktahuan! Saya telah melewatkan fitur itu dalam dokumentasi. Maaf; tolong abaikan.

saya akan melakukan

// @ts-abaikan-mulai
--strick null cek, untuk satu file tertentu

Inilah tampilan unittesting private field dan method dengan TypeScript. Saya memiliki 6 baris yang didedikasikan untuk mengabaikan kode. Buruk sekali. Membuat mataku berdarah. Solusi apa pun untuk pengabaian blok akan sangat dihargai.

it('TestNode_ReconnectionsWorkload', async function () {
    for (let i = 0; i < 1; i++) {
        nodes.push(await Node.NewNode(serverUrl, {
            handlers: {
                active: async function (n: Node) {
                    try {
                        // @ts-ignore
                        if (n.view.Empty()) {
                            // @ts-ignore
                            if (n.conns.Empty() && !n.server) {
                                // @ts-ignore
                                await n.login(n.address);
                            }
                            return;
                        }

                        const data = new flats.Message({
                            // @ts-ignore
                            id: n.id,
                            type: flats.MessageType.Data,
                            data: 'hello world',
                        });

                        const dataBytes = data.toBytes();
                        const dataBase64 = base64.encode(dataBytes);
                        // @ts-ignore
                        const dataSigBytes = await n.sign(dataBytes);
                        const dataSigBase64 = base64.encode(dataSigBytes);

                        // @ts-ignore
                        for (const conn of n.conns.Iter()) {
                            conn.Send(`${dataBase64}.${dataSigBase64}`);
                        }
                    } catch (error) {
                        console.log(error);
                    }
                },
            },
        }));
    }

    for (const node of nodes) {
        await node.Wait();
    }
});

Yah, saya akan menambahkan masalah baru, tapi saya rasa masalah ini sudah mencakupnya.

@ts-ignore menangani impor multi-baris dan satu-baris yang berbeda!

Masih banyak modul npm yang tidak memiliki pengetikan, atau ditulis tanpa NoImplicitAny,
yang menghasilkan kesalahan "implisit apa pun" kemudian diimpor:

import { a, b } from 'MyNonTypedModule' // <-- Implicit any error

Jadi saya bisa menggunakan @ts-ignore:

//@ts-ignore
import { a, b } from 'MyNonTypedModule'

Tetapi ketika saya bekerja dengan impor otomatis dan pemformat seperti Prettier, ini terjadi:
(Diformat oleh Lebih Cantik)

//@ts-ignore
import { 
  a, 
  b 
} from 'MyNonTypedModule' // <-- Still (again) getting the Implicit any error

Saya dapat memperbaikinya dengan:

import { 
 a, 
 b
//@ts-ignore
 } from 'MyNonTypedModule'

atau

//@ts-ignore-start
import { 
   a, 
   b
} from 'MyNonTypedModule'
//@ts-ignore-end

Tetapi kemudian mulai terlihat seperti ini pada impor satu baris:

//@ts-ignore-start
import { a } from 'MyNonTypedModule'
//@ts-ignore-end
import { b } from 'SomeTypedModule'
//@ts-ignore-start
import { c } from 'SomeOtherNonTypedModule'
//@ts-ignore-end

Jadi saya harus menulisnya seperti ini karena impor otomatis dan pemformatan akan berubah antara impor satu baris dan multi-baris tergantung pada berapa banyak elemen yang diimpor dari modul.
Itu benar-benar mengalahkan tujuan impor otomatis jika saya mengubah kode impor secara manual.

Akan lebih baik untuk tidak harus menulis ts-ignore-start dan ts-ignore-end pada setiap impor,
Jadi: //@ts-ignore untuk impor (bukan hanya baris berikutnya) menurut saya adalah sesuatu yang harus ditangani oleh ts-ignore. (Atau abaikan lainnya seperti: @ts-ignore-block / @ts-ignore-import )

saya perlu menekan kesalahan tertentu di seluruh file:

// @ts-ignore-all TS1206

/*
... rest of the file
*/

Sesuai dengan orang-orang di atas yang menyarankan komentar // @ts-ignore-start dan // @ts-ignore-end untuk menangani kasus penggunaan yang disebutkan di utas ini.

Ini bagus, karena terlihat sangat mirip dengan direktif // @ts-ignore saat ini, dan memungkinkan Anda untuk mengabaikan semua kesalahan dalam file hanya dengan direktif // @ts-ignore-start di bagian atas.

Ada kasus penggunaan positif untuk sejumlah saran di atas. Saya melamar:

@ts-ignore sebagai perilaku saat ini
@ts-ignore TSxxx [TSxxx ...] menekan kesalahan tertentu
@ts-ignore-start mulai blokir untuk diabaikan
@ts-ignore-start TSxxx [TSxxx ...] menekan kesalahan tertentu untuk blok
@ts-ignore-end akhir blok
@ts-ignore-all menekan kesalahan untuk sisa file
@ts-ignore-all TSxxx [TSxxx ...] menekan kesalahan tertentu untuk sisa file

"Kesalahan spesifik" dapat mencakup grup bernama yang mirip dengan yang ada di tsconfig atau grup kesalahan TSxxx yang ditentukan pengguna.

Saya tidak yakin tentang nilai blok abaikan yang menyarangkan modul yang diimpor; preferensi saya akan secara eksplisit mengabaikan blok di dalam file modul yang diimpor. Tetapi ketika mengimpor lib pihak ke-3 mungkin ada alasan untuk ini, jadi saya ragu-ragu di sini.

file .tsignore yang diinginkan

seperti .npmignore & .gitignore

Harus ada blok abaikan. Saya terjebak dengan kerangka dalang. Di dalang Anda telah "mengevaluasi" metode yang memungkinkan Anda menjalankan blok skrip arbitrer pada halaman. Blok skrip arbitrer ini dapat berisi referensi ke fungsi yang tersedia di halaman dengan kata lain referensi fungsi akan tersedia saat runtime.

// @ts-ignore-start
// @ts-ignore-end

Ini akan sangat berguna saat bekerja dengan potongan kode lama, sehingga tidak terlalu menyakitkan bagi orang-orang untuk beralih ke TypeScript.

Tentang

// @ts-ignore-start
// @ts-ignore-end

Saya membuat saran ini sebelumnya dan ingin mengubah sintaks.
Entah membuatnya mulai-berhenti atau mulai-akhir
start dan end (sebagai kata kerja) bukan antonim dan ini akan mengganggu saya selamanya jika masuk ke TypeScript.

Itu keren dengan saya

// @ts-ignore-begin
// @ts-ignore-end

Fungsionalitas yang sangat dibutuhkan.

Mengapa ini masih tidak mungkin? :-(

Saya perlu blok abaikan juga

+1

+1

ada pembaruan tentang ini?

🙏🏻

Dan jika kita melakukannya sama seperti yang biasa kita lakukan dengan eslint?

/* @ts-disable */

!function(){
  // no ts here!
}()

/* @ts-enable */

Seperti disebutkan di atas: Segera setelah Anda membuat kode TS (misalnya dengan kesombongan) di mana misalnya vars yang tidak digunakan mungkin terjadi, Anda memerlukan fitur ini.

+1

Tanpa //@ts-ignore-file tidak mungkin bermigrasi ke TS

Jadi, Tanpa Siapa Pun Memperhatikan tidak benar

@RyanCavanaugh Komunitas jelas membutuhkan ini, apakah ada alasan mengapa ini belum ditangani? Terima kasih!

Saya berjuang dengan ini sekarang karena saya bahkan tidak bisa bermain-main dengan mendapatkan solusi yang berfungsi untuk melihat apakah itu layak tanpa Typescript menangis dan memblokir render saya.

Kami sedang membutuhkan fitur ini.

Kami mengimpor perpustakaan umum yang memiliki tipe Node untuk beberapa fungsi yang tidak kami minati. Jadi alangkah baiknya menggunakan // @ts-ignore untuk satu impor, daripada menggunakan skipLibCheck untuk mengabaikan semua lib.

Awalnya saya suka // @ts-ignore-file ide, tapi // @ts-ignore mungkin akan bekerja lebih baik demi konsistensi.

Jadi.... Saya membuka #33383 dengan dukungan untuk //@ts-nocheck dalam file TypeScript. Sekarang, kami sebagai tim penyusun _TypeScript_, kami sendiri tidak benar-benar mengerti (tidak memperbaiki kemungkinan masalah, whaaat!!?!?) - bahkan //@ts-ignore dalam TypeScript hanya menjadi masalah karena lengan kami terpelintir sedikit, jadi kami.... ragu-ragu... untuk menambahkan mekanisme penekanan lebih lanjut. Jadi jika Anda benar-benar merasa diperlukan mekanisme penindasan yang luas, alangkah baiknya jika Anda bisa pergi ke sana dan 👍

@weswigham , Meskipun ini mungkin bukan fitur yang paling penting. Ini bisa berguna selama pengembangan. Sama seperti mengomentari beberapa baris kode sementara, ini bisa membantu saat mengembangkan dan mencoba mengisolasi masalah di tempat lain. Namun saya ingin mendapatkan peringatan sehingga praktik ini tidak akan menemukan cara untuk benar-benar menyebabkan bug waktu berjalan. Bahkan mungkin mengaktifkan fitur ini untuk pengembangan saja, tetapi untuk menimbulkan kesalahan pada build.

Karena masalah ini masih berlabel "Menunggu Lebih Banyak Umpan Balik", berikut ini selengkapnya:

Saat membuat prototipe arah arsitektur baru dengan cepat, saya ingin melakukannya dengan dipandu oleh TypeScript, untuk memastikan arsitektur baru akan berfungsi. Namun, saya ingin mengabaikan sementara kesalahan tipe dalam file unit test , hanya sementara, sementara saya bereksperimen.

Menambahkan semacam komentar @ts-ignore- di bagian atas setiap file akan cukup mudah.

Saya mendukung kebutuhan @ kumar303 : dalam pengujian unit, bermanfaat untuk mematikan beberapa pemeriksaan untuk blok/file yang diberikan, karena itu akan menjadi pernyataan yang akan mencakup kasus-kasus itu.

@weswigham Anda bisa meletakkannya di belakang flag compiler.

Anda bisa meletakkannya di belakang flag compiler.

Tidak perlu - itu dalam versi 3.7 beta.

re: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham itu bagus, terima kasih! Kasus penggunaan yang kuat di sini adalah untuk sementara mengabaikan pemeriksaan jenis dalam file, jadi saya sarankan juga untuk mengirimkan aturan lint yang gagal ketika seseorang lupa menghapus @ts-nocheck

Mengalami masalah pada gatsby, di mana kueri graphQL statis berfungsi di file .jsx , tetapi tidak di file .tsx . Saya pikir proposisi ini bisa menjadi solusi yang lebih dapat diterima. (terbitkan di sini https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

Hai!
Apakah solusi yang diusulkan telah dilaksanakan?

// @ts-abaikan-mulai
// @ts-abaikan-akhir

Saya pikir itu akan sangat bermanfaat. Saya tidak keberatan mengerjakannya.

Kami menambahkan dukungan untuk //@ts-nocheck untuk menekan semua kesalahan di seluruh file di 3.7. Saya pikir penekanan level-line dan level-file dapat mencakup _most_ kebutuhan tanpa banyak keributan. Jika Anda memiliki blok yang cukup besar di dalam file yang dicentang yang seharusnya tidak dicentang, mungkin nonaktifkan pemeriksaan untuk seluruh file atau, jika itu tidak menyenangkan, ekstrak potongan yang tidak dicentang ke filenya sendiri dan nonaktifkan pemeriksaan untuk file itu atau, jika gagal, menekan setiap baris dengan masalah yang sebenarnya? ts-ignore seharusnya mengabaikan satu masalah, sedangkan ts-nocheck seharusnya mengabaikan satu file - penindasan berbasis rentang tidak benar-benar memetakan ke unit tertentu dengan cara apa pun, jadi tampaknya entah bagaimana lebih buruk (karena tidak dapat dipetakan ke satu masalah atau akar penyebab yang Anda tekan). Setidaknya tanpa penekanan khusus kode kesalahan, saya tidak terlalu nyaman dengan penekanan berbasis rentang.

Saya, setidaknya, lebih suka satu penekanan ( //@ts-nocheck File is a legacy untyped UMD module concatenated into the build - declarations are pulled from node_modules, so errors here are hopefully meaningless ) di bagian atas file atau penekanan individu ( //@ts-ignore The TS compiler doesn't support the assignment on the next line because we never declare it, but we provide this for legacy compat ) pada setiap hal buruk individu(tm). Saya tidak dapat, seumur hidup saya, membuat contoh yang meyakinkan dan berprinsip di mana _rentang_ kode tertentu harus dibiarkan tidak dicentang (tidak seperti file, yang memiliki alasan yang didukung oleh strategi migrasi yang jelas), selain "menulis beberapa kali berturut-turut penindasan membuat mata saya berdarah", yang saya _zero_ simpati karena, pada dasarnya, kami percaya Anda tidak boleh menggunakan penindasan di TypeScript sama sekali. Jika ini masalah tipe, Anda dapat membuangnya (itulah sebabnya any , casting, dan deklarasi modul steno ada). Jika itu masalah sintaks, semuanya buruk dan kami akan tetap rusak, jadi penekanan tidak akan melakukan apa-apa (penindasan tidak mempengaruhi kesalahan parse).

Terima kasih untuk //@ts-nocheck , tetapi ini tidak menyelesaikan masalah menonaktifkan pemeriksaan untuk blok kode:

const $element = document.createElement('iframe')
$element.loading = 'lazy' // Property 'loading' does not exist on type 'HTMLIFrameElement'.

// @ts-nocheck

Saya memiliki kasus penggunaan yang menarik.

Kami membangun atau memiliki ORM di TypeScript yang menggunakan acorn untuk mengkompilasi pernyataan ke dalam DDL kami.

Untuk melakukan kueri di mana kita harus meneruskannya ke variabel cakupan:

.entities
.include('parent')
.where(m => m.id === this.id, { id: this.entityId })
.toList()

Ini tidak bekerja hanya karena: Property 'id' does not exist on type 'xxx'

Jika saya membungkusnya dengan @ts-ignore-start itu akan berfungsi dengan baik seperti ini:

// @ts-ignore-start
.where(m => m.id === this.id, { id: this.entityId })
// @ts-ignore-end

Tetapi ketika yang diformat datang dan mulai menambahkan jeda baris:

// @ts-ignore-start
.where(m => m.id === this.id || m.id === this.id2, {
  id: this.entityId,
  id2: this.entity2Id
})
// @ts-ignore-end

Ini tidak berfungsi lagi.

Ini tidak berfungsi hanya karena:

Itu persis jenis kesalahan tingkat tipe yang seharusnya Anda miliki as any cast (atau, di jsdoc, /** <strong i="8">@type</strong> {any} */(expr) ) pada aksesnya, jika Anda benar-benar ingin menekannya.

//@ts-nocheck tidak berfungsi untuk proyek sudut ts saya tetapi //@ts-ignore berfungsi. Masalah ini untuk microsoft dimulai pada 2017. 2017! Wow...

3 tahun sekarang dan tidak ada solusi. Tidak mengherankan bahwa mungkin pengembang JavaScript tidak ingin melompat ke TypeScript

// @ts-ignore-start
// @ts-ignore-end

Dapat dikombinasikan dengan: #19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn ini bukan tslint.

Adakah rencana untuk menerapkan ini?

// @ts-nocheck
adalah satu-satunya pilihan saat ini :(

Kasus penggunaan lain untuk ditambahkan untuk dipertimbangkan di sini ...

Saya membuat kode yang menghasilkan banyak kode TypeScript dari bahasa markup internal yang memungkinkan beberapa aliran dan persyaratan kontrol dasar. Sementara saya mengontrol perilaku pembuatan kode, saya tidak mengontrol input yang diteruskan ke pembuat kode (terserah pengguna akhir)

Akibatnya, kode yang dihasilkan mungkin dengan mudah memiliki kode yang tidak dapat dijangkau, atau dalam satu kasus TS2367 karena mungkin ada kode bersarang yang menguji nilai terhadap konstanta enum, kemudian di dalam blok itu berisi pemeriksaan lain dari variabel tersebut terhadap konstanta enum lainnya. Sebagai contoh:

if (foo === MyEnum.ONE) {
  const bar = (foo === MyEnum.TWO ? "two" : "one");
}

Dengan kode tulisan tangan, pola ini mudah diperbaiki dan dihindari. Namun, dengan pembuatan kode, terserah kepada pengguna saya (pengembang, Anda tahu tipenya!) untuk tidak memberikan input yang secara tidak perlu menguji nilai yang tidak mungkin.

Saya tidak ingin menonaktifkan pemeriksaan tipe secara langsung, tetapi saya tidak memiliki mekanisme lain untuk menggunakan kode yang dihasilkan kode karena kesalahan ini. Idealnya saya akan menekan kesalahan yang satu ini untuk semua file yang dihasilkan kode, tetapi mempertahankan semua pemeriksaan tipe lainnya.

Karena itu, saya tidak punya solusi selain mematikan semua pemeriksaan tipe. Pada titik mana saya tidak mendapatkan banyak nilai dari TypeScript vs JavaScript biasa

Apakah kamu serius? Ini masih merupakan masalah terbuka dan tidak diterapkan di TS4? 🤦🏽.

@ivnnv Anda dapat menggunakan // @ts-expect-error di TS 3.9, lihat di sini

@ndraiman @ts-expect-error berfungsi untuk masing-masing baris tetapi tidak untuk blok , jadi masih diperlukan untuk menempatkan banyak dari mereka jika seseorang ingin "mengabaikan satu blok"

Berikut beberapa umpan balik untuk Anda:

Apa lagi yang Anda butuhkan? Apa yang harus dilakukan komunitas untuk mendapatkan fungsi ini?

Kasus penggunaan terbaik untuk ini adalah alternatif untuk menulis any pada setiap jenis yang dibuat. Anda mungkin tidak bersimpati pada estetika (yang tidak diragukan lagi berdampak pada suasana hati dan produktivitas), tetapi hanya memiliki alternatif yang sesuai dengan harapan umum seharusnya tidak sulit diterima.

Orang memiliki pandangan berbeda tentang apa yang dapat diterima dan apa yang tidak.

Bagi sebagian orang, ini terlalu memakan waktu dan membatasi keadaan aliran yang dapat dilakukan orang saat melakukan hal-hal biasa seperti kode porting.
Saya merasa menjengkelkan dan aneh bahwa saya tidak dapat mengabaikan blok kode tetapi malah harus membuangnya dengan any gips, yang seringkali memiliki efek merugikan pada keterbacaan (sampai jenis yang tepat ada di sana). Harus terus-menerus menulis komentar baru atau terlibat dalam gangguan _hanya karena seseorang tidak melihat manfaat dari mengabaikan blok kode_ tidak apa-apa dalam perspektif saya.

CONTOH:

Salah satunya adalah port proyek dari JS ke TS, dengan proyek lain yang dikembangkan oleh pihak ketiga.

Sintaks dan aturan yang diikuti dalam proyek yang di-porting dapat berupa yang lama, mis., es2015, atau tidak digunakan lagi demi sintaks yang lebih jelas dan kode yang lebih sedikit, dll.

Saat mem-port proyek ini, beberapa kode mungkin sangat mudah untuk di-port ke TypeScript. Tetap saja, seseorang pasti mengalami, misalnya, setengah berpikir melalui boolean dan fungsi dengan perilaku arbitrer yang membutuhkan lebih banyak konteks atau harus dipikirkan selama beberapa waktu untuk membuat tipenya.

Akan sangat luar biasa untuk berhenti memeriksa fungsi atau blok kode dalam file sambil memperbaikinya. Mengabaikan blok kode akan memungkinkan seseorang untuk bergerak cepat di area yang mereka ketahui dan nyaman serta menyimpan bagian tertentu untuk nanti.

Alur kerja saya ketika saya harus mem-port JavaScript ke TypeScript (dan kodenya, yah, di bawah standar):

1. Salin kode dari file .js ke .ts.
2. Lihat apakah TS dapat menyimpulkan jenis apa pun berdasarkan penggunaan
3. Memahami jenis secara manual dari penggunaan
4. Sadarilah kesalahan adalah kutukan keberadaanku
5. Cobalah untuk mengomentari kesalahan, sehingga meningkatkan jumlah baris dalam file terkadang x3 ESLlint + TS (lebih banyak lebih baik?)
6. Hapus dan tambahkan // @ts-check di bagian atas sambil dengan hati-hati mengedit sisa file & menambahkan lebih banyak jenis.

Jika kita bisa mengabaikan blok:

1. Salin kode dari .js ke .ts
2. Lihat apakah TS dapat menyimpulkan jenis apa pun berdasarkan penggunaan
3. Memahami jenis secara manual dari penggunaan
4. // @ts-ignore-enable ... // @ts-ignore-disable fungsi individu & blok kode yang merepotkan
5. Batalkan komentar blok saat saya membukanya dan menambahkan jenis

Putuskan sendiri apa yang tampaknya paling masuk akal. Itu sama ketika mem-porting JS ke proyek dengan lebih banyak aturan ESLint, dan Anda harus memfaktorkan ulang sebagian besar hal.

Saya berharap kita bisa melakukan seperti yang mungkin dilakukan di ESLint dan menggunakan /* eslint:disable */ ... /* eslint:enable */ di TypeScript.

PS Saya baru menyadari ketika memeriksa komentar ini bahwa saya telah menghabiskan 20 menit+ mencoba untuk mendapatkan pengalaman yang saya (dan banyak lainnya) telah cari sejak 2017, hanya untuk mengomentari masalah terbuka segera 3 tahun.

@weswigham @RyanCavanaugh

Pengingat :+1:

Akan memberikan anak sulung sebagai ganti ini

@agusterodin Pengorbananmu menarik perhatian kejahatan.....

Baiklah, sebenarnya tidak ada yang terjadi, kecuali saya hanya memberikan PR sederhana :)

Namun, secara pribadi, saya sangat setuju dengan pendapat tim TS -- fungsi ini jahat, Anda harus selalu mencoba untuk menghindari penggunaan @ts-ignore , bukan untuk menggunakan @ts-ignore-enable (atau @ts-ignore-start , apa pun).
Tapi terkadang, Anda tahu, pepatah mengatakan drinking posion to satisfie thirst , saya tahu itu pilihan yang buruk, tetapi itu hanya perlu.

edit: tambahkan penjelasan dan contoh.
PR ini menambahkan dua direktif ts-ignore-enable dan ts-ignore-disable .

1. jika hanya menggunakan ts-ignore-enable, bagian lainnya diabaikan.

...   <-- this is normal
// @ts-ignore-enable
XXX    <-- this is ignored
...    <-- this is ignored

1. anda dapat menambahkan arahan yang sama berkali-kali, tetapi hanya berfungsi sekali.

// @ts-ignore-enable
XXX  <-- this is ignored  
// @ts-ignore-enable       <-- you could remove this line.
YYY   <-- this is ignored
// @ts-ignore-disable
ZZZ   <-- this is normal
// @ts-ignore-disable      <-- you could remove this line.

1. // @ts-ignore-disable dapat digunakan sendiri, tidak akan terjadi apa-apa.

2. @ts-expect-error tidak akan berfungsi di wilayah yang diabaikan

// @ts-ignore-enable
XXX  <-- this is ignored
// @ts-expect-error       <-- No error message. whatever next line has error or not.
YYY   <-- this is ignored

1. tidak ada label wilayah, mereka hanya berkomentar.

// @ts-ignore-enable A
XXX  <-- this is ignored  
// @ts-ignore-enable   B    <-- you could remove this line.
YYY   <-- this is ignored 
// @ts-ignore-disable B
ZZZ   <-- this is normal
// @ts-ignore-disable A     <-- you could remove this line.

Di dunia yang sempurna, kita tidak perlu mengabaikan keamanan tipe, kan? :keringat_senyum:
Saya membutuhkannya saat menyalin karya fantastis misalnya, contoh dan permulaan, bahkan jawaban SO sesekali yang tidak diketik atau diketik seperti yang saya inginkan. Sebagian besar untuk memilikinya dalam kode tipe-aman saya yang mengikuti pengaturan saya. Saya hanya menggunakan pengaturan yang sangat ketat dan sering harus menulis ulang suatu fungsi atau logika karena itu. Bukan karena saya ingin terus mengabaikan blok kode itu, itu tidak masuk akal.

Mengabaikan blok kode adalah suatu kemudahan, yang bagi saya, tampaknya sangat masuk akal mengingat fakta bahwa saya masih dapat @ts-ignore setiap baris dalam satu blok.

Saya memahami kemungkinan implikasi ini bagi orang-orang yang pergi I'll just ignore this because it's easier . Seperti yang saya lihat, siapa pun yang dapat menggunakan block scope mengabaikan drink poison to satisfy their thirst sudah meminum racun dengan @ts-ignore .

Sekarang Anda dapat melakukan @ts-nocheck dalam file .ts , saya sarankan untuk mengizinkan @ts-check dalam file .ts juga sehingga kami dapat mematikan/mengaktifkan pemeriksa tipe:

import fs from 'fs'

fs.readFileSync(32423) // type checking

// @ts-nocheck
fs.foobarbaz() // type checking is off
fs.__randomThing()

// @ts-check
fs.readFileSync(123) // now type checking again

Ini tidak perlu mendefinisikan apa itu "blok kode". Anda dapat memulai dan menghentikan pemeriksaan jenis dari - ke baris mana pun.

UPDATE Saya salah, lihat https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 untuk koreksi.

Saat mencoba memigrasikan aplikasi menggunakan styled-components ke TypeScript, saya mengalami masalah di mana @ts-ignore tidak dapat digunakan di atas string template (untuk beberapa alasan). Itu bisa diselesaikan dengan blok abaikan.

Contoh kesalahan TS yang saya coba abaikan:

import styled from "styled-components";
import { Button } from "...";

// @ts-ignore here does not work
const StyledNavBar = styled.div`
  ${Button} {
    margin: auto 0;
  }
`;

Sebagai catatan tambahan: Saya tidak dapat memasukkan apa pun di proyek TS saya, saya tidak mengizinkan jenis apa pun. Lalu apa rekomendasinya?

@weswigham Apa pendapat Anda tentang kondisi aliran, dan produktivitas dalam konteks estetika? Tampaknya Anda tidak memiliki simpati untuk mata berdarah; tetapi apakah Anda memiliki gagasan tentang produktivitas, kode porting, dan proses yang saya jelaskan? Apakah Anda masih tidak melihat manfaat _sama sekali_, setelah mempertimbangkan komentar saya, dan dalam konteks menjadi lebih produktif? Saya juga menjelaskan beberapa situasi nyata di mana seseorang perlu mengabaikan cakupan blok. Selanjutnya, bagaimana fungsi ini tidak dibandingkan dengan ESLint dan fungsionalitas yang kami harapkan di sana?

Terbukti secara ilmiah bahwa lebih sedikit interupsi meningkatkan produktivitas dan meningkatkan efisiensi; pengabaian cakupan blok akan memungkinkan lebih sedikit interupsi saat mem-porting kode. Apakah tim TS tidak menyadari bahwa "pada dasarnya, kami yakin Anda tidak boleh menggunakan penekanan di TypeScript sama sekali." adalah pendapat berdasarkan TypeScript yang hidup dan bernafas, dan bahwa di dunia nyata, orang perlu mem-porting kode yang ditulis dengan buruk ke basis kode lain, dengan lebih banyak keamanan jenis dan aturan linting lainnya; dalam situasi tersebut, tidak masuk akal bahwa Anda dapat mengabaikan file atau baris, tetapi bukan blok kode yang baru saja Anda impor.

Bagi saya, sepertinya Anda mencari utopia sambil mengabaikan kenyataan. @sandersn Anda tidak membahas poin saya dan menahan respons lama atas diskusi baru dalam kasus ini. Anda juga menyatakan bahwa kecuali tim memutuskan sebaliknya, itu tidak boleh diterapkan, dalam hal ini: tutup masalah?

Tim perlu membuat keputusan atau menerapkan fitur yang jelas diinginkan.

Menjaga masalah dalam limbo tidak masuk akal.

Maaf kami tidak dapat memberikan finalitas yang Anda butuhkan, tetapi kenyataannya adalah bahwa "mungkin nanti" adalah jawaban yang harus Anda pelajari untuk hidup dengannya. Setiap fitur yang diberikan tidak dapat terburu-buru ke dalam produk besok, dan untuk fitur yang termasuk dalam parameter desain kami, ada ribuan saran yang saat ini terbuka bersaing untuk kapasitas kami untuk menambahkannya ke produk dengan cara yang ergonomis, berguna, stabil, dan berpikiran maju.

Kami memprioritaskan hal-hal berdasarkan umpan balik saat ini, keadaan solusi dan solusi saat ini, skenario yang lebih dominan, peralatan, dan seratus faktor lainnya. Hal-hal yang tidak menjadi prioritas tinggi saat ini dapat menjadi prioritas tinggi di kemudian hari. Itu adalah sifat dari "mungkin nanti" dan saya pikir itu adalah representasi akurat di mana saran ini berdiri. Keputusan di sini, untuk saat ini, adalah untuk terus memantau umpan balik dan memahami apa yang dihadapi orang-orang yang mungkin memerlukan fitur ini sebagai prioritas yang lebih tinggi daripada fitur lain yang mungkin kami tambahkan berikutnya, di mana ada ratusan yang bersaing untuk mendapatkan perhatian.

Nada di sini jujur ​​cenderung ke arah permusuhan dan berbicara secara pribadi, didorong ke arah ultimatum tidak kondusif untuk percakapan konstruktif yang membantu kita memahami di mana ini adalah nilai tambah yang melebihi kompleksitasnya relatif terhadap alternatif.

Saya minta maaf tentang menetapkan ultimatum. Saya cukup kesal melihat aktivitas ke arah PR, tetapi tidak ada masalah. Saya setuju bahwa komentar saya sebelumnya tidak berkontribusi secara konstruktif.

Saya dapat menerima bahwa masalah ini mungkin perlu menunggu. Saya memberikan beberapa umpan balik dan telah menanyakan umpan balik apa lagi yang diperlukan untuk mendekati resolusi, tetapi saya tidak mendapat tanggapan. Tampaknya, betapapun menjengkelkannya, bahwa komentar saya yang agak tidak membangun adalah apa yang perlu saya lakukan untuk mendapatkan _beberapa_ tanggapan dari tim.

Tampaknya masih belum ada kemajuan nyata menuju masalah dengan lebih dari 700 reaksi positif, yang berusia beberapa tahun, telah dibuat. Saya tidak percaya itu harus berjalan lebih cepat, tetapi sepertinya tim tidak tertarik untuk menjelajahi fitur ini karena anggota memiliki pendapat pribadi yang menentangnya. Saya sangat memahami semua hal ini. Bukan itu yang saya bicarakan di sini. Saya ingin memulai percakapan, tetapi saya diabaikan.

Saya ingin tahu bahwa umpan balik saya dipertimbangkan, dan mengingat sifatnya, ditanggapi. Ini bukan gangguan besar di set fitur, ditunjukkan oleh PR aktif yang dikocok dalam waktu singkat. Semuanya sudah siap, orang-orang terus bereaksi positif untuk menyelesaikan masalah ini dengan fitur abaikan blokir, dan saya menimpali menanyakan apa yang harus dilakukan komunitas untuk mendapatkan fitur ini. Saya sangat tidak setuju dengan beberapa poin yang dibuat dari tim dan menentangnya, PR dibuat dan komentar yang diberikan menyatakan bahwa 'kecuali kita berubah pikiran' tidak akan ada yang berubah.

Di situlah kekesalan saya muncul ke permukaan. Anda ingin mengabaikan fitur siap pakai karena tidak ada perubahan yang dibuat terhadap keputusan dari anggota tim, sama sekali mengabaikan umpan balik saya sendiri dan orang lain.

Tampaknya kecuali seseorang dalam tim memutuskan sebaliknya _sesuai keinginannya_, kami tidak akan melihat perubahan apa pun pada masalah ini. Itu tidak membutuhkan lebih banyak umpan balik dari komunitas, bukan? Itu sebabnya saya salah membuat ultimatum.

Saya telah membuat beberapa argumen menentang poin @weswigham , memberikan beberapa contoh, dan sejujurnya saya masih menunggu tanggapan untuk itu. Satu-satunya hal yang tampaknya membantu adalah terlihat kesal dan tidak membangun.

Bagaimana kita pindah dari sini? Umpan balik apa yang diinginkan tim? Sepertinya masalah pribadi yang tersembunyi di balik "Kami memprioritaskan hal-hal berdasarkan umpan balik saat ini, keadaan solusi dan solusi saat ini, skenario yang lebih besar, peralatan, dan seratus faktor lainnya." karena beberapa orang telah mencoba memberikan umpan balik tanpa tanggapan _sama sekali_ dari tim.

Saya ingin menegaskan kembali bahwa saya memahami bahwa ini mungkin tidak menjadi prioritas tinggi jika kita mengambil pendapat orang dari subjek. Pada saat yang sama, fitur siap diimplementasikan, dan argumen telah dibuat. Yang dibutuhkan sekarang adalah tim membuat keputusan/tanggapan (tidak harus mengimplementasikan apa pun) dan mengumumkannya kepada publik. Jika bukan itu yang diperlukan, tolong beri tahu saya apa itu, atau bagaimana seseorang akan membantu meningkatkan prioritas pada fitur _any_ atau masalah untuk TypeScript, tetapi terutama yang ini.

Kasus penggunaan lain untuk multiline ( @ts-ignore-start+@ts-ignore-end ) atau inline (seperti /* @ts-ignore */ ) @ts-ignore .
Lingkungan:

• "noUnusedParameters": true
• Aturan require-jsdoc ESLint diaktifkan.
• Kode yang mirip dengan berikut (contoh sederhana):

type Data = Record<string, unknown>;
type PrepareSettings = Record<string, unknown>;

/**
 * This is base class that will be inherited.
 */
class SuperClass {
    /**
     * Prepare data for further usage.
     * 
     * <strong i="16">@param</strong> data
     *      Data that should be prepared.
     * <strong i="17">@param</strong> settings
     *      Operation settings.
     */
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {
        return data;
    }

    // Some additional methods...
}

Untuk situasi yang dijelaskan TypeScript mengeluarkan peringatan berikut: 'settings' is declared but its value is never read.(6133) .
Dimungkinkan untuk menekan peringatan dengan menambahkan @ts-ignore setelah akhir komentar dokumentasi:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {

Tapi setelah itu ESLint akan mengeluh tentang Missing JSDoc comment .
Jadi solusinya adalah:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {   // eslint-disable-line require-jsdoc

Yang canggung dan jelek.

@RyanCavanaugh @weswigham @sandersn

Pengingat bulanan bahwa ini adalah sesuatu yang komunitas ingin diskusikan lebih lanjut dengan tim TypeScript. Ada banyak dukungan dan apa yang hilang saat ini adalah respons dari tim. Saya mengerti bahwa ada banyak pertimbangan, dan mengembangkan TypeScript bukanlah hal yang mudah. Hal-hal membutuhkan waktu. Karena tidak ada tanggapan tentang bagaimana kami dapat melanjutkan saran ini dan mengambil tindakan langsung, saya akan membuat pengingat seperti ini secara teratur. Saya tidak menyerah sampai keputusan telah dibuat, dan komentar tampaknya mempengaruhi (kebanyakan ketika menjadi !@# sekalipun).

Setelah bertahun-tahun berlalu, meskipun saya awalnya takut bagaimana fungsi ini tidak ada, saya pribadi memikirkannya kembali sedikit... Ketika ada banyak @ts-ignore , Anda mungkin sudah mengatakan bahwa ada sesuatu yang salah dengan kode Anda, dan luangkan waktu untuk meningkatkan tipe Anda. Kita semua terkadang sangat malas, dan menginginkan kecepatan secara keseluruhan, tetapi saat ini seringkali lebih mudah untuk mengetahui beberapa jenis yang tepat daripada menyalin-menempelkan beberapa @ts-ignore ke dalam kumpulan besar kode. Jika keseimbangan ketidaknyamanan ini akan rusak, banyak dari kita akan dengan mudah menyalahgunakan @ts-ignore-enable, yang mungkin hanya menurunkan kualitas keseluruhan dari semua proyek open source kecil di sana-sini.

Btw, meskipun kita melihat bahwa ada banyak 👍 reaksi tentang masalah ini, - mungkin bias, karena lebih banyak orang mungkin merasa baik-baik saja tanpa fitur ini saat diam, karena mereka tidak ada di sini.

@JerryGreen Merujuk komentar saya yang lebih lama, saya telah mengatakan hal yang persis sama. Dengan tambahan bahwa orang sudah melakukan ini dengan fitur abaikan. Tidak ada alasan untuk menerapkan sedikit racun sambil mengklaim harus ada _none_ .

Hapus fungsi @ts-ignore atau buat sepenuhnya. Ada banyak argumen untuk melakukan ini, dan orang yang menulis kode yang buruk akan terus menggunakan @ts-ignore yang sama buruknya dengan fitur abaikan blok, mereka adalah hal yang sama persis - kecuali untuk pengabaian blok yang kurang mengganggu secara visual.

Komunitas masih membutuhkan tanggapan dari tim TypeScript.

@JerryGreen Merujuk komentar saya yang lebih lama, saya telah mengatakan hal yang persis sama. Dengan tambahan bahwa orang sudah melakukan ini dengan fitur abaikan. Tidak ada alasan untuk menerapkan sedikit racun sambil mengklaim harus ada _none_ .

Hapus fungsi @ts-ignore atau buat sepenuhnya. Ada banyak argumen untuk melakukan ini, dan orang yang menulis kode yang buruk akan terus menggunakan @ts-ignore yang sama buruknya dengan fitur abaikan blok, mereka adalah hal yang sama persis - kecuali untuk pengabaian blok yang kurang mengganggu secara visual.

Komunitas masih membutuhkan tanggapan dari tim TypeScript.

Beberapa skenario khusus masih perlu menggunakan @ TS abaikan. Misalnya, impor CDN tidak bergantung pada node_ The. File TS tidak ada dalam skenario modul

@L-Hknu Terima kasih telah mengklarifikasi. Orang-orang menggunakannya karena mereka menggunakan abaikan dengan ESLint.

Fungsi abaikan tidak dilarang dalam konteks selain yang diperlukan untuk fungsionalitas. Itu memberitahu saya tidak apa-apa menggunakannya untuk mengabaikan kode.

Saya masih tidak dapat menjelaskan mengapa tidak ada blok yang diabaikan, karena sering digunakan dengan cara yang sama.

Saya telah membuang konversi ke tipe untuk beberapa kode sumber terbuka, karena kemajuan konversi akan jauh lebih nyaman dengan pengabaian blok. Saya tidak membutuhkannya, tetapi saya pikir banyak orang akan masuk ke dalam pintu dengan mengetik; lebih jauh, banyak orang kemungkinan besar akan berkontribusi pada konversi dengan lebih efisien, terutama mengingat betapa berbedanya estetika antara komentar blok dan setiap baris.

Kasus penggunaan terbesar saya untuk implementasi ini adalah untuk paket pihak ketiga yang tidak memiliki dukungan TypeScript, dan saya harus mengabaikan beberapa penggunaannya.

@L-Hknu Terima kasih telah mengklarifikasi. Orang-orang menggunakannya karena mereka menggunakan abaikan dengan ESLint.

Fungsi abaikan tidak dilarang dalam konteks selain yang diperlukan untuk fungsionalitas. Itu memberitahu saya tidak apa-apa menggunakannya untuk mengabaikan kode.

Saya masih tidak dapat menjelaskan mengapa tidak ada blok yang diabaikan, karena sering digunakan dengan cara yang sama.

Saya telah membuang konversi ke tipe untuk beberapa kode sumber terbuka, karena kemajuan konversi akan jauh lebih nyaman dengan pengabaian blok. Saya tidak membutuhkannya, tetapi saya pikir banyak orang akan masuk ke dalam pintu dengan mengetik; lebih jauh, banyak orang kemungkinan besar akan berkontribusi pada konversi dengan lebih efisien, terutama mengingat betapa berbedanya estetika antara komentar blok dan setiap baris.

Sepertinya sudah selesai
#40267