Apakah Anda menggunakan beberapa alat bundling lain seperti browserify atau webpack pada output yang dihasilkan? atau apakah Anda mengharapkan ini berjalan langsung di node?

Jika perilaku ini dimaksudkan, lalu bagaimana peta jalur dapat digunakan untuk menyelesaikan neraka-impor-relatif dalam hubungannya dengan simpul?

Nah dan untuk menambahkan konteks, "paths" dirancang untuk digunakan dengan loader yang memungkinkan pemetaan ulang, tidak seperti Node.js require() . Perilaku yang dimaksud adalah mengizinkan TypeScript untuk menyelesaikan informasi jenis untuk berbagai ID modul yang digunakan oleh berbagai pemuat, bukan untuk menulis ulang ID modul. Pada dasarnya itu tidak melakukan apa yang Anda pikirkan. Juga tidak menurut pendapat saya, itu seharusnya hanya memiliki kemampuan untuk mencerminkan strategi resolusi pemuat.

@mhegazy Saya berharap ini berfungsi secara langsung dengan node.js. Ini untuk aplikasi backend. Apakah @kitsonk benar dalam menyatakan bahwa ini berfungsi sebagaimana dimaksud dan TypeScript tidak akan menulis ulang jalur modul?

ya, ini maksudnya - untuk mengurangi ketidakcocokan antara waktu proses dan pengalaman waktu desain ketika modul (seperti yang ditulis oleh pengguna) dapat diselesaikan dalam waktu proses tetapi gagal ditemukan oleh kompiler. Pada titik ini kompiler selalu menganggap bahwa modul id yang diberikan oleh pengguna benar dan tidak pernah mencoba untuk mengubahnya.

tanggapan serupa https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

Baiklah, terima kasih. Mungkin berguna untuk mendokumentasikan ini dengan lebih baik untuk mencegah lebih banyak orang menjadi bingung. Saya sekarang menggunakan https://www.npmjs.com/package/module-alias untuk membuatnya bekerja dengan node.js.

Menghargai posisi TS, inilah solusi sederhana untuk kasus penggunaan 90% bagi kita yang menggunakan node, tetapi menginginkan kenyamanan menggunakan baseUrl relatif require() panggilan tanpa keributan.

Solusi ini mengaitkan panggilan require() node, dan menyelesaikan permintaan menggunakan dirname "main" untuk meniru baseUrl . Oleh karena itu diasumsikan opsi kompiler baseUrl juga disetel ke direktori yang sama di mana sumber "main.ts" berada.

Untuk menggunakannya, tempelkan potongan kecil kode ini di bagian atas "main.ts" Anda.

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

Jika Anda akan menggunakan paket module-alias yang disebutkan mika-fischer, perhatikan bahwa jalur yang Anda daftarkan ke paket tidak boleh diakhiri dengan / , dan jalurnya relatif terhadap jalur di mana package.json berada (mungkin jelas tetapi ada baiknya untuk memperjelasnya),

Jadi jika Anda memiliki ini di file tsconfig Anda:

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

Anda harus mendaftarkan ini di package.json Anda :

"_moduleAliases": {
  "foo": "dist"
}

Nah dan untuk menambahkan konteks, "jalur" dirancang untuk digunakan dengan pemuat yang memungkinkan pemetaan ulang, tidak seperti kebutuhan Node.js(). Perilaku yang dimaksud adalah mengizinkan TypeScript untuk menyelesaikan informasi jenis untuk berbagai ID modul yang digunakan oleh berbagai pemuat, bukan untuk menulis ulang ID modul. Pada dasarnya itu tidak melakukan apa yang Anda pikirkan. Juga tidak menurut pendapat saya, itu seharusnya hanya memiliki kemampuan untuk mencerminkan strategi resolusi pemuat.

Sampai di sini setelah membuang waktu mencoba memasangnya di proyek besar.
Jika perilaku ini tidak akan berubah, paling tidak yang dapat Anda lakukan adalah memperbarui dokumentasi sebelum menutup masalah ini.
Dokumentasi resmi https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping%20docs tidak mengatakan apa-apa tentang harus menggunakan "loader yang memungkinkan pemetaan ulang" apa pun.

instal dan jalankan "tspath" di folder proyek Anda... https://www.npmjs.com/package/tspath

@ef-carbon/tspm

Anda juga dapat mencoba "momothepug/tsmodule-alias" ke alias resolusi jalur:

https://www.npmjs.com/package/@momothepug/tsmodule -alias

Hanya https://www.npmjs.com/package/module-alias yang berfungsi untuk saya...

Saya juga berhasil membuatnya bekerja dengan modul-alias, dengan kerugian saya harus melacak alias saya baik di dalam tsconfig.json dan package.json. Adakah yang menemukan solusi yang lebih sederhana?

Solusi yang ditunjukkan oleh @mattyclarkson juga berfungsi, tetapi saya tidak dapat menemukan cara untuk menggunakannya secara berdampingan dengan ts-node. Ada ide?

Lihatlah https://github.com/momoThePug/tsmodule-alias

2018-05-31 15:04 GMT-05:00 edufschmidt [email protected] :

Saya juga berhasil membuatnya bekerja dengan modul-alias, dengan sisi negatifnya
bahwa saya harus melacak alias saya baik di dalam tsconfig.json dan
paket.json. Adakah yang menemukan solusi yang lebih sederhana?

Solusi yang ditunjukkan oleh @mattyclarkson
https://github.com/mattyclarkson juga berfungsi, tetapi saya tidak dapat menemukan cara
menggunakannya berdampingan dengan ts-node. Ada ide?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

Terima kasih @DanyelMorales , ini sangat berguna.

Terima kasih kembali! :)

2018-05-31 16:35 GMT-05:00 edufschmidt [email protected] :

Terima kasih @DanyelMorales https://github.com/DanyelMorales , ini benar-benar
berguna.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

Adakah yang bisa memberi tahu saya apa gunanya fitur ini jika nama jalur yang dipancarkan sebenarnya salah? Artinya, jika kompiler TypeScript senang dengannya, tetapi hasil akhirnya tidak dapat dijalankan - apa gunanya fitur ini?

Bagaimana seharusnya seseorang melakukan pemetaan jalur relatif untuk hal-hal yang BUKAN modul, yaitu bukan impor?

Dalam skrip simpul yang membaca direktori tertentu relatif terhadap file sumber yang biasa saya lakukan:

const starterDir = path.resolve(__dirname, './templates/starter')

karena TypeScript mengkompilasi skrip dan menulisnya ke direktori lain (berdasarkan konfigurasi), __dirname tidak akan lagi mengarah ke penyelesaian jalur di atas. Apa yang akan menjadi solusi untuk ini?

Bagaimana seharusnya seseorang melakukan pemetaan jalur relatif untuk hal-hal yang BUKAN modul, yaitu bukan impor?

Itu benar-benar "bagaimana cara menggunakan pertanyaan Node.js dan TypeScript" dan jauh lebih baik ditanyakan di Gitter.im atau StackOverflow.

Saya suka TypeScript tapi ini gila.

Saya tidak mengerti. Meskipun saya hanya tahu sedikit tentang basis kode TS, ini seharusnya tidak sulit untuk diterapkan. Saya baru saja mulai menggunakan proyek bersama dengan klien dan server... mengapa TS menyajikan fungsionalitas jalur di tempat pertama, lalu membuat saya melompat melalui rintangan untuk benar-benar menggunakannya? Mengapa TS berasumsi bahwa saya ingin menggunakan bundler/loader dengan setiap proyek yang saya buat? Saya mencoba menggunakan TS untuk menyederhanakan proyek saya, bukan menggunakan lebih banyak pustaka perkakas untuk mengimbangi 90% fitur TS yang diimplementasikan.

Saya setuju denganmu. Saya pikir, TS dikembangkan untuk frontend, karena webpack
sudah mengimplementasikan jalur alias ts dengan cukup baik, dan dengan Requirejs juga
hal yang sama. Tetapi untuk proyek Nodejs itu sangat sulit. :(

El jue., 20 de september de 2018 02:50, Josh Pike [email protected]
penjelasan:

Saya tidak mengerti. Bahkan dengan saya yang tahu sedikit tentang basis kode TS, ini
seharusnya tidak sulit untuk diterapkan. Saya baru saja mulai menggunakan proyek bersama
dengan klien dan server... mengapa TS menghadirkan fungsionalitas jalur di
tempat pertama, lalu membuat saya melompat melalui rintangan untuk benar-benar menggunakannya? Mengapa
apakah TS berasumsi bahwa saya ingin menggunakan bundler/loader dengan setiap proyek saya?
membuat? Saya mencoba menggunakan TS untuk menyederhanakan proyek saya, bukan menambahkan lebih banyak
pustaka perkakas untuk mengimbangi 90% fitur TS yang diimplementasikan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

+1!

webpack dapat membantu saya menyelesaikan peta jalur (atau alat lain seperti babel-plugin-module-resolver ) tetapi bukan deklarasi ( .d.ts ) .

Semua jalur dalam deklarasi tidak diselesaikan.

Berlari ke masalah ini juga. Tampak logis bahwa kode yang dipancarkan akan mencakup pemetaan jalur. Menggunakan module-alias . Tetapi +1 untuk TypeScript untuk menyediakan fungsionalitas ini secara opsional.

Bisakah ini tidak hanya ditambahkan sebagai opsi kompiler? Jelas itu permintaan yang populer. Tidak tahu apa-apa tentang cara kerja kompiler, bukankah seharusnya mengimplementasikannya menjadi sangat sederhana? Mengapa memaksa kita untuk melompati rintangan di tempat lain ketika itu dapat dengan mudah diselesaikan secara langsung dengan kompiler TypeScript, di mana itu paling masuk akal?

+1

Anda dapat mengkompilasi impor TypeScript absolut dan berbasis jalur ke file Javascript relatif menggunakan ts-transformer-imports dan ttypescript

Saya telah membuat solusi waktu kompilasi di mana Anda dapat terus menggunakan tsc . https://github.com/joonhocho/tscpaths

Microsoft/TypeScript#15479 (komentar)

Saya baru saja menemukan masalah ini ketika mencoba membuat vue-cli untuk menampilkan file d.ts di mana ada banyak import {foo} from "@/some/folder/foo" dan file d.ts yang dikeluarkan tidak menyelesaikan alias.

Dari pencarian umum dan melihat-lihat utas ini dan lainnya, sepertinya reaksi brengsek lutut adalah "ini bukan masalah yang harus diselesaikan TS" tetapi saya akan meminta tim untuk mengubah sikap itu seperti saat ini jika Anda menggunakan jalur khusus alias (sepenuhnya valid dan pendekatan yang direkomendasikan untuk proyek kompleks) Anda tidak dapat menggunakan file generate d.ts (tanpa proses pembuatan pihak ke-3 khusus) jadi saya akan mengatakan bahwa kompiler TypeScript juga harus menyelesaikan alias ini dalam proses file deklarasi juga.

Pekerjaan kompiler adalah untuk menampilkan file javascript DAN d.ts yang valid untuk file TypeScript Anda, dan itu tidak berfungsi dalam skenario yang valid ini (menggunakan path alias 'dalam file tsconfig).

Saya agak bingung dengan masalah ini. Itu telah ditutup dan diberi label 'Bekerja seperti yang Dimaksudkan'. Apakah saya harus memahami TypeScript dimaksudkan untuk menghasilkan sumber yang tidak valid? Tampaknya aneh.

Pengemis tidak bisa menjadi pemilih, tetapi menggunakan TypeScript menghindari banyak aspek yang membuat frustrasi dari Vanilla JS dan saya menghitung impor relatif ('../../../../../utils/parser') sebagai salah satunya. Akan luar biasa jika TypeScript bisa membersihkan ini!

@codeitcody Sepertinya begitu. Bodoh bahwa itu akan menghasilkan sesuatu yang tidak berfungsi tanpa beberapa paket pihak ketiga tetapi itulah kenyataannya.

Nah, bukankah ini masalah yang bagus untuk dihadapi.

Tampaknya sangat kontraproduktif untuk memiliki fitur yang pada dasarnya membuat aplikasi Anda tidak dapat digunakan tanpa melewati rintangan (yaitu memasang lebih banyak dependensi untuk mengatasi masalah ini).

Isu ini sudah ada selama 2 tahun dan belum ada kabar resmi apakah akan diimplementasikan atau tidak.

Mempertimbangkan ini diperlukan dan fungsionalitas dasar untuk menggunakan salah satu fitur terbaik TypeScript dalam proyek Node.js Anda, cukup mengerikan bagaimana hal itu diperlakukan.

@mhegazy Bisakah Anda atau orang lain memberi tahu kami jika sekarang dua tahun kemudian mungkin tim TypeScript mungkin akan melihat ini lagi dan mempertimbangkan kembali?

webpack dapat membantu saya menyelesaikan peta jalur (atau alat lain seperti babel-plugin-module-resolver ) tetapi bukan deklarasi ( .d.ts ) .

Semua jalur dalam deklarasi tidak diselesaikan.

Apakah ada cara untuk mencapai ini? Saya memiliki pustaka komponen reaksi khusus dan saya mendapatkan kesalahan ini ketika mencoba menggunakan paths untuk alias. Saya melakukan 2 bundel dengan rollup dan tipe dengan --emitDeclarationOnly

Saya tidak dapat menggunakan module-alias karena tertulis:

PERINGATAN: Modul ini tidak boleh digunakan di modul npm lain karena memodifikasi perilaku kebutuhan default!

Tolong bantu upvote posting ini di Reddit: https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
Tidak tahu mengapa perlu diskusi besar ini di sini. Seharusnya mudah untuk memecahkan bug ini. Opsi di tsconfig dan semua orang dapat memutuskan apakah dia menginginkan perilaku saat ini (untuk alasan apa pun) atau pendekatan yang berfungsi.

Kami memiliki masalah yang sama di Dropbox dan membuka sumber transformator ini https://github.com/dropbox/ts-transform-import-path-rewrite

Saya telah memiliki pengalaman yang sama beberapa kali sekarang, saya berharap alias path akan diselesaikan tetapi saya terus lupa bahwa saya harus menginstal module-alias, memperbarui package.json dan mengimpornya di file utama. Akan luar biasa jika ini ditangani dalam langkah kompilasi oleh TypeScript.

Aduh. Ini adalah pukulan nyata bagi TypeScript. Di mana arti dalam hal ini?

ps Bisakah kita tidak berkomentar +1

Selamat datang di klub @def14nt. Kami adalah sekelompok pemimpi yang bahagia, dengan mata berbinar saat kami menatap masa depan yang lebih baik, dengan sabar menunggu hari ketika TypeScript akan mengimplementasikan opsi kompiler yang sederhana dan masuk akal untuk membuat hidup kita lebih mudah. Ketika hari itu akhirnya tiba, pastikan untuk memeriksa langit untuk mencari tubuh merah muda gemuk babi saat mereka terbang dengan anggun ke matahari terbenam dengan sayap baru mereka.

Lol, saya hanya akan menginstal ekstensi npm untuk sesuatu yang dapat ditambahkan oleh tim TypeScript. Mungkin mereka harus berhenti menambahkan lebih banyak dan lebih banyak peningkatan dan menambahkan fitur yang mendasar ini.

@mika-fischer
Bagaimana cara menggunakan https://www.npmjs.com/package/module-alias sehingga eslint berhenti untuk memperingatkan tentang 'Jalur yang tidak terselesaikan '@root/bla/bla' (dalam file JS)? Dan bagaimana cara mengaktifkan pelengkapan otomatis untuk jalur seperti itu di WebStorm dan VS Code?

Bagi saya, pelengkapan otomatis impor berfungsi di VSCode secara default di proyek TypeScript.

@bobmoff Ya, sepertinya semuanya baik untuk mengimpor file TS dari file TS.
Tetapi pelengkapan otomatis dan navigasi untuk `require('@root/bla/bla') dari file TS tidak berfungsi.

Saya ingin menerjemahkan proyek JS saya ke TS, dan berpikir bahwa saya dapat mengganti nama file js menjadi ts satu per satu.
Sekarang saya menyadari bahwa ini sangat sulit dan tidak didukung baik oleh ts maupun oleh IDE, dan saya harus mengganti nama semua file js saya menjadi ts sekaligus.

Karena jika saya mengganti nama hanya satu file JS menjadi TS, semua jalur relatif di direktori build menjadi rusak (mungkin saya harus menggunakan "allowJs: true", tetapi saya punya satu proyek dengan 2 Gigabytes file JS, jadi aneh untuk mengkompilasinya ke build dir %)).
Oke, saya mencoba menyelesaikan ini dengan modul-alias, dan navigasi IDE saya dan pelengkapan otomatis berhenti berfungsi dan eslint memperingatkan sekitar 100500 'Jalur yang belum terselesaikan'. Saya sudah agak membenci TS, sepertinya migrasi untuk proyek JS besar tidak semudah yang dikatakan orang pemasaran TS. Sepertinya migrasi proyek backend JS ke golang lebih sederhana :)

Saya berhasil menggunakan tscpaths sebagai solusi.

Gerakan mengungkap kekerasan seksual demi menghapuskannya. Saya sangat merekomendasikan tscpaths . Ia bekerja sebagaimana mestinya.

Solusi sederhana saya:

node -r ts-node/register/transpile-only -r tsconfig-paths/register index.js

Atau dengan proses pm2.yml

apps:
  - name: 'my-app'
    script: './dist/index.js'
    instances: 'max'
    exec_mode: 'cluster'
    out_file : '/dev/null'
    error_file : '/dev/null'
    node_args: ['--require=ts-node/register/transpile-only', '--require=tsconfig-paths/register']
    env_production:
      NODE_ENV: production

Baru saja menemukan ini, terkadang TypeScript bisa sangat menyebalkan.

Saya benar-benar tidak mengerti mengapa utas ini terus berlanjut dan terus menerus ....
Kita semua tahu tentang "jalan neraka", dan bahwa Anda (dengan menggunakan alias) bisa
benar-benar bersih
sampai kekacauan itu, semua orang di utas ini tahu ini!

Alias ​​​​diinterpretasikan oleh kompiler TypeScript, itu dikompilasi dengan tepat
seperti seharusnya,
itu pasti tidak mencari-cari di javascript yang dihasilkan, jika
Anda ingin menggunakan
alias Anda harus menyelesaikan ini sendiri!

....atau memulai utas di Apple, Google, dan Microsoft
meminta mereka untuk mengimplementasikan fungsionalitas di mesin JavaScript mereka sehingga
mereka bisa
interpet alias kamu ;-)

Kompiler TypeScript melakukan persis seperti yang seharusnya!

Jika Anda bekerja di dunia Angular, jalannya diaspal, jika Anda mau
jalankan
kode langsung di Node Anda akan memerlukan alat untuk menyelesaikan jalur, dan saya punya
dibuat
alat tersebut hanya untuk Anda, telah digunakan dalam produksi selama lebih dari satu tahun sekarang,
itu sedang
digunakan oleh surat kabar terbesar di sini di Swedia, saya membuat ini agar Anda bisa
telanjang
tulang dengan Node, saya tidak mencoba menjual apa pun di sini, saya tidak menghasilkan uang
dari sini :)

Dan ya, ada alat seperti "tsmodule-alias" dan peretasan serupa, Anda bisa
benar-benar membuatnya bekerja
jika Anda sangat sangat berhati-hati, tetapi berantakan, ada solusi menggunakan
ts-simpul,
skrip shell dll dll...yadda yadda

Saya akhirnya merasa itu sudah cukup jadi saya mengunci diri dan membuat
TsPath
alias waktu kompilasi

> npm install -g tspatj

proyek saya> tsc

proyek saya> tspath

atau

proyek saya> tspath --f

headless (terbukti sangat berguna di server build)

dan kemudian Anda selesai, file javascript Anda sekarang memiliki
jalur relatif yang benar, bukankah itu yang kita inginkan di sini?

Bersulang! :)

https://www.npmjs.com/package/tspath

Den son 13 jan. 2019 kl 22:20 skrev Fabio Spampinato <
[email protected]>:

Baru saja menemukan ini, terkadang TypeScript bisa sangat merepotkan
pantat.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

@duffman

Alias ​​​​diinterpretasikan oleh kompiler TypeScript, itu dikompilasi dengan tepat
sebagaimana mestinya, itu pasti tidak melihat-lihat javascript yang dihasilkan, jika
Anda ingin menggunakan alias, Anda harus menyelesaikannya sendiri!

Sangat tidak setuju. Kecuali Anda bercanda, saya benar-benar tidak tahu.

TypeScript harus mengkompilasi kode yang _works_ tanpa memerlukan alat pihak ketiga untuk menyelesaikan pekerjaan yang hanya sebagian diimplementasikan ke dalam kompiler asli.

Kompiler TypeScript melakukan persis seperti yang seharusnya!

Jika utas ini penuh dengan orang yang meminta tsc juga melakukan minifikasi atau semacamnya, saya setuju dengan Anda. Namun tidak. Orang-orang yang meminta kompiler menghasilkan kode yang dapat dieksekusi. Saya benar-benar tidak berpikir itu terlalu banyak untuk diminta dari kompiler, bukan?

Dan itu menghasilkan kode yang dapat dieksekusi jika Anda tidak menggunakan fitur yang
tidak didukung oleh Mesin JavaScript, itu seharusnya masuk akal kan
di sana, misalnya: apakah Anda akan menyalahkan kompiler C++ jika aplikasi Anda
menggunakan pustaka tautan dinamis dan program tidak akan berjalan di mesin
yang tidak memiliki ini diinstal?

Ini adalah fitur yang dapat digunakan jika Anda mengelola jalur relatif,
bertanggung jawab atas mereka seperti yang dilakukan Angular dengan WebPack atau seperti yang saya lakukan dengan
semua proyek TypeScript saya dengan TSPath!

Jangan gunakan jika Anda tidak mengerti cara mengatur lingkungan kerja,
Saya benar-benar tidak berpikir bahwa ini adalah tanggung jawab Microsoft di sini, mereka
menyediakan fitur dan inilah cara kerjanya,
itu mungkin tidak berfungsi seperti yang Anda inginkan atau harapkan itu berfungsi tetapi itu tidak membuat
itu salah!

Juga, saya ingin tahu, apakah Anda serius membiarkan ini menghalangi Anda dari
berkembang menggunakan TypeScript?

Den mn 14 jan. 2019 kl 21:34 skrev Robert Notifikasi [email protected] :

Kompiler TypeScript melakukan persis seperti yang seharusnya!

Jika utas ini penuh dengan orang yang meminta tsc juga melakukannya
minifikasi atau semacamnya, saya setuju dengan Anda. Namun tidak. Dia
orang yang meminta agar kompiler menghasilkan kode yang dapat dieksekusi. aku benar-benar
jangan berpikir itu terlalu banyak untuk diminta dari kompiler, bukan?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

Ini adalah fitur yang dapat digunakan jika Anda mengelola jalur relatif, bertanggung jawab atas mereka seperti yang dilakukan Angular dengan WebPack atau seperti yang saya lakukan dengan semua proyek TypeScript saya dengan TSPath!

Ini adalah fitur yang membuat kompiler mengeluarkan kode yang rusak, kode yang dapat berfungsi jika mereka hanya menulis 1 baris kode untuk menyelesaikan jalur tersebut dengan benar.

Fakta bahwa TS membutuhkan bundler eksternal hanya agar kode yang dihasilkan dapat dieksekusi adalah hal yang konyol.

Dan itu menghasilkan kode yang dapat dieksekusi jika Anda tidak menggunakan fitur yang
tidak didukung oleh Mesin JavaScript,

Saya selalu mengerti bahwa TypeScript seharusnya dikompilasi ke JavaScript. Jika Anda memberi tahu saya bahwa fitur-fitur tertentu tidak didukung oleh mesin JavaScript, lalu mengapa mereka ada di sana?

apakah Anda akan menyalahkan kompiler C++ jika pustaka tautan dinamis aplikasi Anda dan program tidak akan berjalan pada mesin yang tidak menginstal ini?

Tidak, tetapi saya akan menyalahkannya jika membiarkan saya menautkan ke kode C++ lain yang sebenarnya tidak ada tanpa kesalahan atau peringatan kompiler.

Anda benar-benar tidak mengerti ini, bukan? Kode tidak rusak, jika itu
rusak itu karena Anda telah mengonfigurasi kompiler
untuk menghasilkan kode yang "platform" Anda tidak mendukung, dalam hal ini,
alias!

Dalam kasus Anda, jangan gunakan alias, "Anda" tidak mendukungnya, serius!

Bahkan jika ini akan menjadi perbaikan 1 baris (tentu saja bukan itu masalahnya)
masalah apa yang harus dilakukan oleh kompiler dan
tidak harus dilakukan! Fitur ini telah ditambahkan untuk MENDUKUNG LOADERS bukan
sebaliknya, baca
pada Pemetaan Jalur dalam dokumentasi resmi, jadi sekali lagi, Anda menggunakannya
salah!

Sekali lagi, fitur ini untuk Loader/Resolver, Anda salah paham caranya
berfungsi, jadi tidak, Microsoft
tidak boleh mengubah kompiler sehingga Anda dapat menempelkan alias tanpa
lingkungan yang mendukungnya!

Den tis 15 jan. 2019 kl 04:41 skrev Fabio Spampinato <
[email protected]>:

Ini adalah fitur yang dapat digunakan jika Anda mengelola jalur relatif,
bertanggung jawab atas mereka seperti yang dilakukan Angular dengan WebPack atau seperti yang saya lakukan dengan
semua proyek TypeScript saya dengan TSPath!

Ini adalah fitur yang membuat kompiler mengeluarkan kode yang rusak, kode yang
bisa berfungsi jika mereka hanya menulis 1 baris kode untuk menyelesaikannya
jalan.

Fakta bahwa TS membutuhkan bundler eksternal hanya agar kode yang dihasilkan
dapat dieksekusi adalah konyol.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

Mereka ada sejak Loader menggunakan Pemetaan Jalur, itu sebabnya didukung!
Dan karena Anda bersikeras (seperti saya) untuk menggunakannya tanpa Loader, apa yang
masalah dengan
menggunakan alat sehingga Anda dapat menggunakan fitur tersebut?

Den tis 15 jan. 2019 kl 05:10 skrev Robert Notifikasi [email protected] :

Dan itu menghasilkan kode yang dapat dieksekusi jika Anda tidak menggunakan fitur yang
tidak didukung oleh Mesin JavaScript,

Saya selalu mengerti bahwa TypeScript seharusnya dikompilasi untuk
JavaScript. Jika Anda memberi tahu saya bahwa fitur tertentu tidak didukung oleh
Mesin JavaScript lalu mengapa sebenarnya mereka ada di sana?

apakah Anda akan menyalahkan kompiler C++ jika tautan dinamis aplikasi Anda?
perpustakaan dan bahwa program tidak akan berjalan di mesin tidak memiliki ini
diinstal?

Tidak, tapi saya akan menyalahkannya jika membiarkan saya menautkan ke kode C++ lain yang tidak
sebenarnya ada tanpa kesalahan atau peringatan kompiler.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

Dengar, aku mengerti maksudmu. Saya bersedia. Tetapi bagian dari pekerjaan kompiler adalah memeriksa kewarasan untuk terakhir kalinya. Pada kode terbaik yang dikompilasi tetapi tidak berjalan adalah perilaku yang tidak konsisten dan ketika saya pertama kali membaca masalah ini, dokumentasi tampaknya menyarankan perilaku yang jelas tidak ada di sana

Tolong arahkan saya ke bagian dokumentasi itu.

ini 15 jan. 2019 kl. 05:31 skrev Robert Notifikasi [email protected] :

Dengar, aku mengerti maksudmu. Saya bersedia. Tetapi bagian dari pekerjaan kompiler adalah untuk kewarasan
memeriksa hal-hal untuk terakhir kalinya. Pada kode terbaik yang mengkompilasi tetapi tidak berjalan adalah
perilaku yang tidak konsisten dan ketika saya pertama kali membaca masalah ini
dokumentasi tampaknya menyarankan perilaku yang jelas-jelas tidak ada

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

Fitur ini telah ditambahkan untuk MENDUKUNG LOADERS bukan
sebaliknya, baca
pada Pemetaan Jalur dalam dokumentasi resmi, jadi sekali lagi, Anda menggunakannya
salah!

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

@duffman Tidak bisakah Anda melihat bahwa orang-orang di sini hanya menginginkan fitur ini??? Anda memberi tahu semua orang bahwa dia terlalu bodoh untuk memahami bagaimana "fitur" ini harus digunakan. OK - Anda dapat melihat ini seperti itu tetapi siapa tahu - mungkin sebaliknya ...

Omong-omong, pendapat saya adalah sebagai berikut:

Karena alias dibangun di dalam kompiler dan kompilasi proyek dengan mereka tidak masalah. Ini mungkin membuat pengguna berpikir, bahwa itu berfungsi seperti yang disarankan (dan masalah ini adalah bukti yang cukup bagus bahwa saya benar). Bahkan tampaknya tidak masuk akal - mengapa sesuatu bekerja di editor "resmi" (vscode - terutama ketika menggunakan fitur "impor otomatis", vscode menggunakan jalur alias), mengapa copyer juga berfungsi dengan baik, ketika kode yang dihasilkan tidak berfungsi? Mengatakan "mesin js tidak mendukungnya" membuat saya ingin bertanya lebih banyak - bukankah TS dimaksudkan sebagai sesuatu untuk mengurangi beberapa "masalah" JS?

Saya mengharapkan salah satu dari dua solusi ini:
1) Mengganti impor dengan alias dengan benar
2) Menampilkan peringatan

Mengatakan "itu perilaku yang benar", menurut saya, salah. Ini bukan. TS bukan bahasa rakitan, bahkan bukan C/C++.

Tim pengembangan harus menambahkan dukungan untuk resolusi alias. Saya sarankan tambahkan
kunci untuk resolusi kompiler di tsconfig.

Akan menyenangkan Microsoft!!!!!!

Kami mohon, kami membutuhkan bantuan Anda untuk meningkatkan aplikasi dengan alias.

:( semua orang di sini sedih dan marah(, dan lapar) karena lag
konsistensi. TypeScriptnya keren, saya suka...

Kami menyukainya!

Hormat kami pengembang tunawisma ...

El mar., 15 de ene. de 2019 08:02, Mike S. [email protected]
penjelasan:

Omong-omong, pendapat saya adalah sebagai berikut:

Alias ​​​​dibangun di dalam kompiler, kompilasi tidak masalah. Ini mungkin membuat pengguna
berpikir, bahwa itu harus bekerja seperti yang mereka pikirkan (dan masalah ini cukup banyak
bukti bagus itu benar). Tampaknya tidak logis - mengapa sesuatu bekerja di
editor "resmi" (vscode - terutama saat menggunakan fitur "impor otomatis",
vscode menggunakan jalur alias), mengapa copyer juga berfungsi dengan baik, saat menghasilkan kode
tidak bekerja? Mengatakan "mesin js tidak mendukungnya" membuat saya ingin bertanya
terlebih lagi - bukankah TS dimaksudkan sebagai sesuatu untuk mengurangi beberapa "masalah" JS?

Saya mengharapkan salah satu dari dua solusi ini:

1. Mengganti impor dengan alias dengan benar
2. Menampilkan peringatan

Mengatakan "itu perilaku yang benar", menurut saya, salah. Ini bukan. TS bukan
bahasa assembly, bahkan bukan C/C++.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

. TS bukan bahasa rakitan, bahkan bukan C/C++.

Saya benar-benar tidak mengerti apa yang Anda coba tunjukkan dengan menetapkan bahwa TS bukan C++, kebanyakan dari kita sangat menyadarinya!

Kami juga telah menetapkan bahwa alias/pemetaan jalur digunakan dalam produksi di seluruh dunia, jadi tentu saja, Kode VS harus mendukung itu, tetapi itu masih bukan argumen bagi MS untuk membuat kompiler yang sesuai dengan pengaturan Anda!

Apa yang sulit saya pahami adalah mengapa Anda terus melakukannya, kompiler berfungsi sebagaimana mestinya, sekali lagi, baca dokumen yang dengan jelas menyatakan untuk apa fitur itu!

Maksud saya, Anda dapat mengatur lingkungan pengembangan TS yang berfungsi dengan alias jalur dalam waktu 2 menit, jika Anda tidak ingin menggunakan WebPack, Anda dapat menggunakan TSPath untuk menyelesaikan semua jalur di semua file js dalam 1 detik, tambahkan ke paket .json sebagai skrip run dan Anda bahkan tidak perlu memikirkannya, masalahnya tidak ada, kompilator tetap seperti yang dimaksudkan untuk berfungsi dan Anda dapat melanjutkan dengan senang hati!?

Atau jika sangat penting bagi Anda bahwa kompiler yang sebenarnya melakukan ini untuk Anda, maka saya sarankan Anda memotong kompiler dan mengimplementasikannya sendiri, mungkin itu akan menjadi sukses besar atau mungkin orang senang dengan cara mereka karena mereka telah menyiapkan lingkungan mereka untuk mendukung alias.

Memanggil lima kontributor TypeScript teratas: @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

Bisakah tim TypeScript mempertimbangkan kembali masalah ini? Saya pikir utas ini menawarkan beberapa diskusi yang berguna tentang kedua sudut pandang dan mengingat popularitasnya baru-baru ini dan jumlah waktu yang telah berlalu, itu harus dilihat lagi.

Status masalah ini membuat saya tidak punya pilihan lain selain menurunkan TS untuk mengetik tugas pemeriksa saja.
Babel sekarang memiliki dukungan yang layak untuk sintaks TS dan bersama-sama dengan babel-plugin-module-resolver melakukan tugas memancarkan kode kerja untuk kasus penggunaan ini dengan baik.
Satu-satunya downside adalah menduplikasi bit konfigurasi dari tsconfig.json karena Babel tidak peduli dengan konfigurasi TS. Tetapi ini adalah harga yang dapat diterima untuk mengerjakan jalur absolut dalam proyek simpul dan sebagai bonus saya mendapatkan seluruh ekosistem dengan hal-hal brilian seperti makro babel.

Ini adalah pengaturan minimum yang saya gunakan sebagai pengganti untuk kompiler tsc :

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• di package.json :
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• di tsconfig.json :

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• di .babelrc :

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

Saya hanya ingin menggunakan TypeScript dengan path absolut, tetapi sepertinya saya harus mengkonfigurasi webpack atau babel atau sesuatu, terlalu sulit untuk mencapai fitur sederhana ini, seharusnya lebih mudah

Saya mengakui masalah ini, saya tidak yakin saya mengetahui hal ini secara spesifik
masalah karena pengaturan pribadi saya sendiri, atau mungkin saya :) itu bukan super
perbaikan berat, perbaikannya hanya (secara membabi buta) mempercayai distPath,
yang sebenarnya kode yang lebih sederhana daripada solusi saat ini, saya akan
coba besok ada perbaikan...

Den mn 28 jan. 2019 kl 15:59 skrev [email protected] :

Saya hanya ingin menggunakan TypeScript dengan jalur absolut, tetapi sepertinya saya harus
config webpack atau babel atau sesuatu, itu terlalu sulit untuk dicapai!!!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

Meninggalkan ini di sini karena kasus penggunaan aktual yang terdokumentasi untuk perilaku paths saat ini tidak disebutkan di utas ini: paket @types/ tidak mendukung fitur yang berkaitan dengan semver. Namun mereka menyertakan jenis yang diperbarui untuk API lama yang dapat saya gunakan. Misalnya saya menggunakan history@2 ketika history@3 adalah yang terbaru.

"paths": {
    "history": [ "history/v2" ]
}

Kompiler akan membutuhkan opsi tambahan untuk membedakan antara alias tipe dan alias "kode". Jika kita mengubah perilaku untuk benar-benar memancarkan alias path, maka kita perlu menambahkan kemampuan ke kompiler untuk menemukan versi tipe yang benar.

Ini bukan argumen yang menentang perilaku yang diusulkan. Saya lebih suka mengeluarkan alias dan hanya ™ solusi yang berfungsi untuk versi tipe. Hanya ingin memberikan beberapa konteks mengapa mengubah ini mungkin tidak sepele seperti yang dipikirkan orang.

Untuk kedua kalinya selama lokakarya TS di seluruh perusahaan, saya harus menjelaskan perilaku gila dan memalukan ini...

Dengan serius!

Kompiler bahasa macam apa, terutama yang promosi penjualan utamanya lebih tepat untuk JavaScript, menghasilkan kode yang rusak sebagai "fitur"?!?!

Saya minta maaf telah terdengar sangat frustrasi dalam komentar saya, tetapi pandangan komunitas di sini tampaknya diabaikan dan diremehkan berulang kali.

Lihat saja berapa kali ini telah dirujuk... Sungguh membuang-buang waktu dan perhatian bagi begitu banyak orang.

Saya memahami rasa frustrasi Anda, tetapi banyak orang merasa suatu perilaku itu benar, bukan berarti itu adalah hal yang benar untuk dilakukan.

Pengidentifikasi modul penulisan ulang TypeScript adalah lereng licin yang licin. Apa yang telah diungkapkan beberapa kali di utas ini adalah bahwa TypeScript dapat dikonfigurasi untuk memodelkan perilaku resolver modul lain dan alat build lainnya, bukan mengganti atau mengimplementasikannya.

Hanya karena TypeScript dapat dikonfigurasi untuk menyelesaikan modul dengan cara yang fleksibel tidak berarti TypeScript mengeluarkan "kode rusak". Loader dan bundler tertentu yang mencerminkan konfigurasi ini akan berfungsi dengan baik.

Jika kami bersikap kritis terhadap apa pun, kami dapat menyalahkan tim karena menamai opsi itu sesuatu yang mungkin terlihat seperti memperbaiki masalah yang tidak pernah dimaksudkan untuk diperbaiki, meskipun dokumentasi untuk opsi memperjelas bahwa itu tidak mengubah emisi .

Karena alat tertentu tidak menyelesaikan masalah yang Anda miliki tidak selalu berarti itu adalah kesalahan alat. Mungkin Anda hanya tidak memiliki semua alat yang Anda butuhkan untuk menyelesaikan masalah Anda.

@kitsonk semua yang baru saja Anda katakan jauh dari sasaran.

Masalahnya adalah TS akan beroperasi satu arah selama pengembangan/pengujian, dan cara lain setelah kompilasi selesai.

Jika TS ingin menjadi penyelesai modul, ia harus memilih pola dan menaatinya. Jika saya menjalankan sesuatu dengan ts-node itu harus beroperasi persis seperti jika saya mengkompilasi beberapa TS dan menjalankannya dengan node .

Tidak, dan itulah masalahnya.

Mungkin peta modul akan mengurangi frustrasi di masa depan. Tapi posisi kami di sini bersama dengan masalah teknis yang ingin kami selesaikan cukup eksplisit - pemetaan jalur mencerminkan perilaku skema resolusi eksternal (misalnya pemetaan jalur di AMD dan System.js, alias di Webpack dan bundler lainnya). Itu tidak berarti kami akan mengubah jalan Anda.

Saya tidak berpikir ada diskusi baru-baru ini yang konstruktif baru-baru ini, saya juga tidak melihat perubahan di masa depan di sini, jadi saya akan mengunci masalah ini.