Typescript: Menekan kesalahan "Jalur impor tidak boleh diakhiri dengan ekstensi '.ts'"?

Misalkan Anda memiliki dua file:
a.ts : import * as b from "./b.ts";
b.ts : export const b: number = 0;

Ketika kita mengkompilasi a.ts , kita tidak mengubah penentu impor . Jadi output a.js akan berisi import specifier yang sama "./b.ts", meskipun mungkin diterjemahkan ke require("./b.ts") .
Kemudian ketika Anda mencoba menjalankan a.js itu akan gagal, karena tidak akan ada b.ts untuk diimpor, hanya b.js . (Atau tanpa --outDir mana b.js berada di sebelah b.ts , itu akan menyelesaikan impor menjadi b.ts , kemudian gagal mem-parsing pada : number . )

Sebaliknya, Anda harus menghilangkan ekstensi file dari impor Anda, atau menggunakan ekstensi .js .

tidak, saya menggunakan deno exec file。 tanpa kompilasi。

@ hooper-h
Saya pikir kita dapat menetapkan tsconfig sebagai solusi sementara seperti ini:

{
  "compilerOptions": {
    "module": "amd",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "http://*": ["../../../.deno/deps/http/*"],
      "https://*": ["../../../.deno/deps/https/*"],
      "*.ts": ["*"]
    }
  }
}

Saya menggunakan deno juga. Saya menemukan bahwa mengomentari // @ts-ignore setiap baris impor berfungsi.

// @ts-ignore
import coerceToArray from './journey.coerce-to-array.ts'
// @ts-ignore
import fnFree from './journey.fn-free.ts'
// @ts-ignore
import fnReduce from './journey.fn-reduce.ts'

Apakah ada cara untuk mematikan persyaratan ini secara global di ts-config?

Saya juga mencoba solusi @zhmushan dan itu tidak memperbaiki masalah :(

@reggi hapus ./
Saya berharap di masa mendatang, kita dapat menggunakan konfigurasi yang mirip dengan module:deno untuk menyederhanakan operasi.

Akankah tim TypeScript terbuka untuk menambahkan "module": "deno" ke tsconfig? Dengan cara itu kami dapat mendukung penggunaan ekstensi .ts secara native, tanpa perlu menggunakan sesuatu seperti kitsonk / deno_ls_plugin sebagai solusinya. Itu juga bisa mencoba dan memaksakannya juga, jadi jika Anda mencoba dan melakukannya

import module from 'module';

itu akan menampilkan kesalahan seperti Cannot have an extensionless import with module:deno (satu-satunya impor yang diperbolehkan adalah URL lengkap, dan impor relatif dimulai dengan ./ atau ../ ). Konfigurasi seperti itu juga dapat mendukung pencarian asli folder $DENO_DIR/deps untuk jenis, karena saat ini kami perlu menggunakan pengaturan jalur untuk mengatasinya. Selain itu, impor otomatis juga dapat berfungsi dengan baik, karena saat ini impor selalu dilakukan tanpa ekstensi (artinya Anda tetap harus mengeditnya secara manual).

Ini sepertinya duplikat dari # 11901 yang sayangnya ditutup dan dibungkam. Ini penting untuk Deno seperti yang telah dikatakan sebelumnya dan saya harap TypeScript akan membuat pemeriksaan ekstensi ini dapat dikonfigurasi atau bahkan lebih baik menghapusnya sama sekali.

Di sebagian besar ekosistem perkakas Javascript, Anda dapat melakukan hal-hal seperti import picture from 'image.png' , yang jelas bukan Javascript. Asumsinya adalah bahwa beberapa alat akan tahu bagaimana mentranspilasi file yang direferensikan ke dalam Javascript sehingga ini bekerja dengan benar. Semua jenis aset dan sintaks alternatif, seperti JSX, bekerja dengan cara ini.

Ketik, di sisi lain, mengharapkan Anda untuk menggunakan ekstensi kosong atau ekstensi .js , yang berbeda dari cara kerja ekosistem lainnya. Ini menyebabkan gesekan untuk alat seperti Deno atau rollup.js yang mengharapkan ekstensi file asli.

Jika tsc ingin bekerja lebih seperti bagian dunia lainnya, ia dapat mengizinkan .ts sebagai ekstensi, dan kemudian mengubahnya menjadi .js sebagai bagian dari jenis pengupasan pada waktu pembuatan. Ini jelas merupakan perubahan besar pada cara kerja kompilator tsc. Di sisi lain, ada gelombang perkakas alternatif berdasarkan Babel dan Sucrase yang mulai memasuki ekosistem, jadi mungkin ada manfaat jangka panjang dalam menyelaraskan dengan cara alat tersebut untuk melakukan sesuatu.

Menambahkan suara saya di sini untuk mendukung Deno. Hasil perilaku saat ini di TypeScript menyelesaikan semua jenis yang diimpor dengan cara ini ke any , yang membuat pengembangan perangkat lunak untuk Deno agak sulit.

Deno adalah ide bagus, tetapi mencoba meyakinkan tim TS untuk secara eksplisit mengizinkan Deno menyelesaikan modul dengan cara itu bagi saya adalah perjuangan yang sia-sia. Jauh lebih mudah bagi Deno hanya untuk menanganinya karena (a) cara yang lebih cepat untuk melakukannya, lebih sedikit usaha yang dibutuhkan dan (b) meyakinkan tim TS untuk memperbaiki internalnya seperti itu adalah perjuangan yang sangat berat.

Jika tsc ingin bekerja lebih seperti seluruh dunia

TS menjadi semakin dominan, merupakan strategi yang baik untuk menjadi sekompatibel mungkin dengan konvensi TS termasuk perkakasnya. Jika tidak, proyek seperti Deno tidak akan pernah mendapatkan daya tarik karena perbedaan dalam sesuatu yang mendasar seperti resolusi modul

@ jpike88 Saya tidak setuju. Saya tidak menyadari masalah ini ada. Ada beberapa masalah lain yang agak terkait yang sedang kami lacak. Masalah ini tidak mengatakan apa-apa tentang tujuan tim. Ini masih diberi label sebagai pertanyaan dan dapat dikatakan itu benar-benar duplikat dari # 16577 atau # 18442.

Komentar Ryan sampai ke inti masalah, bahwa mereka dapat menulis sesuatu yang memuaskan setiap host, jadi mereka membatasinya pada situasi yang paling umum saat ini, yaitu cara CJS Node.js.

Saya masih berpikir (dan saya pikir saya mengatakan ini dalam masalah sebelumnya) adalah bahwa mungkin ada waktu untuk "moduleResolution": "literal" yang akan melakukan apa yang tertulis di kaleng, dan memungkinkan TypeScript untuk berasumsi bahwa host runtime apa pun akan mengetahuinya keluar / ubah penentu modul.

Oke, tapi:

https://github.com/microsoft/TypeScript/issues/18442
Saya benar-benar berkomentar seperti itu dua tahun lalu, dan itu masih proposal tahap 1.

https://github.com/microsoft/TypeScript/issues/16577
Juga di atas dua tahun, masih dalam tahap 'diskusi'. Juga pada tingkat itu, tidak akan terjadi dalam waktu dekat.

Saya hanya membahas skala waktu hal-hal yang telah terjadi di sini, dan mendasarkan kemungkinannya untuk pernah terjadi dalam jangka waktu menengah atau bahkan jangka panjang dari itu.

Masalah ini telah ditandai sebagai 'Pertanyaan' dan tidak melihat aktivitas terbaru. Itu telah ditutup secara otomatis untuk keperluan rumah tangga. Jika Anda masih menunggu jawaban, pertanyaan biasanya lebih cocok untuk stackoverflow .

Masalah serupa terjadi jika Anda ingin mengimpor file .mjs
misal import { forEach } from https://unpkg.com/[email protected]/index.mjs

Ini sudah ditutup, tapi belum diperbaiki.

Jika ada orang di sini yang hanya mencari cara untuk menjalankan TypeScript Anda dalam konteks Node.js dan Deno, ketahuilah bahwa Webpack + ts-loader akan membiarkan Anda menyimpan ".ts" dalam impor Anda.

Saya mengalami masalah ini setiap kali saya mengimpor file dari deno? ada solusi untuk memperbaikinya kecuali menambahkan // @ts-ignore ?

Apakah ini sudah diperbaiki? Mengimpor tanpa ekstensi bukanlah bagian dari JS, menggunakan ekstensi seharusnya tidak menampilkan kesalahan.

Saya setuju dengan komentar di atas. Sayang sekali masalahnya belum terpecahkan.
Saya menemukan ekstensi untuk vscode yang seharusnya membantu, tetapi sayangnya itu tidak berfungsi dengan baik.
Bagaimanapun, saya akan meninggalkan tautan di sini:
1) https://github.com/justjavac/vscode-deno
2) https://github.com/axetroy/vscode-deno

Mengikuti @ TicTak21 :
Tautan yang dia sebutkan sekarang sudah tidak digunakan lagi karena mendukung plugin resmi deno:
https://github.com/denoland/vscode_deno
Ekstensi ini memperbaiki .ts dan impor URL (jadi tidak ada lagi kesalahan) dengan benar,

@danbulant Saya masih melihat kesalahan saat menggunakan plugin vscode_deno.

Saya juga menggunakan Deno tetapi saya pikir masalah di sini bukan tentang .ts vs no .ts . Ini lebih tentang kemampuan untuk mengizinkan tsc mengabaikan nomor kesalahan apa pun. Misalnya, sesuatu seperti tsc --ignore TS2691 .

Ekstensi Deno untuk kode vs bagus, tetapi tidak menyelesaikan masalah, itu hanya menekan kesalahan di editor. Saya memiliki perpustakaan yang ingin saya buat untuk deno dan browser, tetapi saya tidak bisa karena tsc akan membuang.

@samuelindonesia
Saya setuju 100%. Inilah alasan utama mengapa saya belum menganggap Deno sebagai pengganti node.js di server. Kerangka kerja web yang bagus untuk Deno sudah tersedia, dan hanya TYPESCRIPT yang menghalangi mimpi indah ini

Untuk siapa saja yang mengalami masalah baru-baru ini, saya akan mengatakan bahwa deno_ls_plugin meskipun diarsipkan mencapai hasil yang saya butuhkan. Masalah yang mereferensikan plugin ini adalah bagaimana saya mengetahuinya .

Kasus penggunaan khusus saya adalah bahwa saya bekerja di lingkungan dengan kode skrip yang dibagikan antara klien dan server menggunakan symlink. Server ditulis dengan deno dalam pikiran, dan klien ditulis dengan skrip ketikan dan phaser3 biasa. Bundler yang saya gunakan, parcel , dapat menangani pengimporan skrip jenis .ts (setidaknya dengan parcel-bundler ^1.12.4 ). Itu membuat intellisense diperbaiki.

deno_ls_plugin bekerja sangat baik untuk saya, karena secara harfiah hanya menambal resolusi modul .ts . Sempurna! Itu berarti saya dapat mengimpor kode bersama, dan memiliki kode bersama yang ditulis dengan deno depan dan terutama di pikiran, dan menambal intellisense untuk sisi klien skrip ketikan.

Sebagai permulaan, saya menjalankan perintah yarn add typescript deno_ls_plugin --dev untuk menginstalnya. Setelah melihat bahwa intellisense tidak diperbaiki, saya melihat beberapa teks kecil di bagian bawah readme deno_ls_plugin , untuk menggunakan versi ruang kerja dari skrip ketikan .

Bagi orang lain yang agak bingung bagaimana melakukan itu, inilah yang saya lakukan:
Pertama, saya menginstal deno_ls_plugin dan typescript sebagai dependensi pengembangan, dan memperbarui tsconfig.json untuk menyertakan deno_ls_plugin sebagai plugin

{
  "compilerOptions": {
    "plugins": [{ "name": "deno_ls_plugin" }]
  }
}

Kemudian, saya mengklik file skrip dan mengklik versinya di sudut kanan bawah.

Kemudian, saya memilih untuk memilih versi skrip

dan memilih versi ruang kerja.

Dalam kasus khusus saya, saya juga telah menyetel typescript.tsdk di .vscode/settings.json tetapi saya tidak tahu apakah saya perlu melakukannya.

Jika ada orang lain yang juga mencoba membagikan kode deno dengan kode skrip, saya menggunakan symlink untuk menautkan ke kode inti di server dan klien, dan memiliki kode di dalam referensi symlink file deps.ts luarnya untuk dependensi (karena import_map agak meh atm) sehingga versi skrip dapat mengimpor paket npm dan versi deno dapat mengimpor URL.

Semoga pesan kecil ini dapat membantu siapa pun yang memiliki masalah serupa dengan mencoba berbagi kode deno antara proyek skrip klasik dan proyek deno.

Saya membuat masalah saran di sini yang akan menyelesaikan masalah di atas. Mudah-mudahan kita bisa mendapatkan momentum untuk mengimplementasikannya atau yang serupa dalam waktu dekat.

Masalah ini perlu dibuka kembali.

Pengembang Deno tidak mendapatkan rasa hormat yang pantas mereka dapatkan di sini. Mereka membuat runtime yang luar biasa berdasarkan TypeScript, tetapi pengembang TypeScript tidak akan menambahkan bendera untuk memungkinkannya berfungsi dengan baik. Bagaimana situasi yang menyedihkan ini bisa berlangsung lama ?!

Tidak dapat menggunakan ekstensi .ts pada impor menyebabkan rasa sakit dan masalah besar bagi pengguna Deno, tolong bantu kami!

sebenarnya tidak spesifik Deno

tanpa kemungkinan untuk secara eksplisit mendefinisikan ekstensi, banyak pengembang JS akan mengalami masalah

misalnya dalam proyek vue kami selalu menentukan ekstensi, atau kami akan mendapat masalah dalam situasi seperti

./component.vue
./component.ts

import component from './component';

Mengapa ini ditutup? Deno tentu tidak spesifik apalagi dengan maraknya mjs

Utas ini BUKAN pertanyaan, ini adalah permintaan fitur. Tolong bisakah seseorang memperbaiki label dan membukanya kembali? Menambahkan // @ts-ignore secara manual ke setiap impor bukanlah solusi yang dapat diterima.

@tokopedia

Saya telah membaca beberapa utas yang menangani masalah ini. Untuk meringkas, pengembang inti tidak ingin melakukan ini. Mereka mengatakan bahwa itu dapat merusak hal-hal lain dan algoritme impor sudah cukup rumit dan seterusnya.

Anggap saya gila, tetapi menurut saya ada solidaritas korporat di sini. Perusahaan telah menghabiskan banyak uang untuk node (npm). Dan tidak ingin beberapa pemula merampok keuntungan mereka dengan tangannya sendiri .. Jadi saya rasa Anda tidak dapat mengharapkan banyak keramahan terhadap deno dari vscode atau ketikan

Untungnya, Anda dapat menggunakan plugin yang sudah melakukan lebih dari yang Anda minta dan hanya akan menjadi lebih baik.
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

Tapi masalahnya, bukan hanya Deno, tapi juga js biasa
https://github.com/microsoft/TypeScript/issues/27481#issuecomment -664401169

@Hulkmaster

Sepertinya kita membutuhkan skrip baru yang mengkilap. Yang satu ini terjebak dengan masalah lama dan tidak dapat (atau tidak ingin) mengimplementasikan impor dengan ekstensi. Tim deno sepertinya berencana untuk menulis skrip mereka sendiri (di karat, saya kira :)

Saya adalah bagian dari tim inti Deno. Saya setuju bahwa compiler TypeScript tidak boleh terlibat dalam penulisan ulang penentu modul. Internal Deno menyembunyikan pesan diagnostik ini dan plugin vscode untuk Deno juga menghentikan pesan ini. Ini bukanlah penghalang bagi Deno.

Percayalah bahwa tidak ada komplotan rahasia tersembunyi Microsoft / Node.js yang menekan Deno. Tim inti TypeScript, anggota komunitas Node.js dan tim inti Deno secara teratur berbicara satu sama lain dan berkolaborasi.

@tokopedia

Ini bukanlah penghalang bagi Deno.

tetapi ini adalah penghalang untuk penyatuan dua dunia: Node dan Deno. Bagaimana saya bisa menulis skrip yang akan bekerja di kedua platform pada saat yang sama jika kalian memiliki perbedaan pendapat agama tentang mengimpor file lokal dengan atau tanpa ekstensi .. Saya harus memilih sisi

Bagaimana saya bisa menulis skrip yang akan bekerja di kedua platform pada saat yang sama jika kalian memiliki perbedaan pendapat agama tentang mengimpor file lokal dengan atau tanpa ekstensi.

Itu sebenarnya bukan masalah dengan TypeScript / tsc . Node.js memimpin cara modul eksplisit, dan bagaimana mereka mengatasinya yang akan berdampak pada kemampuan resolusi modul tsc Saya curiga. Saya percaya ada percakapan berkelanjutan di sana, untuk dapat mendukung ESM dengan lebih baik di Node.js.

Melakukan seperti yang disarankan masalah ini tidak akan benar-benar membantu siapa pun. Solusi yang lebih baik untuk masalah ini diusulkan di # 33437.