Oh, baru saja melihat https://github.com/feathersjs/feathers/issues/64... Tapi mungkin biarkan ini terbuka? Jadi beberapa orang akan menawarkan bantuan?

Cara terbaik untuk melanjutkan ini adalah dengan memulai repositori dengan beberapa definisi TypeScript dasar (di # 64 saya memposting beberapa petunjuk di mana untuk memulai) dan melanjutkan
diskusi di sana.

Saya dapat membiarkan masalah ini terbuka selama satu atau dua bulan lagi, tetapi masalah lainnya terbuka selama hampir satu tahun tanpa ada yang mengambilnya. Seperti disebutkan di sana, tim inti saat ini tidak menggunakan TypeScript atau Angular sehingga tidak benar-benar ada di radar kami (dan kami lebih suka hanya menjaga masalah tetap terbuka jika ada kemungkinan masalah itu akan ditangani di masa mendatang).

Saya pikir @harangue telah mengerjakan beberapa definisi dasar. Mungkin kita bisa memindahkan diskusi kita di Slack tentang di mana mereka akan tinggal di sini?

Tentu! Jika perlu menutup masalah ini, silakan saja.

Akan sangat bagus jika TypeScript dapat didukung .. bagaimana saya bisa membantu?

@rollymaduk Saya telah membuat beberapa kemajuan yang layak pada definisi untuk Feathers, tetapi kami belum menetapkan cara terbaik untuk mendistribusikannya (dan ada sedikit transisi dengan TypeScript 2 yang akan dirilis). Jika Anda ingin memiliki sesuatu untuk dikerjakan sampai saat itu, Anda dapat melihat intisari yang telah saya kerjakan ini.

@harangue kerja yang sangat bagus ternyata terlihat cukup siap .. Saya kira beberapa area yang mungkin memerlukan perhatian akan menggabungkan beberapa plugin dasar seperti otentikasi, penyedia (istirahat, socke.io, primus) dan beberapa adaptor db kan? tolong apa yang Anda maksud dengan cara terbaik untuk mendistribusikannya?

Saya tidak yakin apakah kita sudah membahas ini, tapi saya pikir akan baik-baik saja jika kita mendistribusikan definisi TypeScript di repositori utama selama ada seseorang yang memelihara dan memperbaruinya. Jadi setelah mereka siap, kita dapat menjadikannya bagian dari rilis Feathers 2.1 (yang menurut saya mungkin juga dikirimkan dengan beberapa peringatan bahwa misalnya panggilan balik dalam layanan akan dihentikan di v3).

Apakah ada garpu generator-feathers untuk TypeScript? Tertarik untuk mengerjakan garpu TS generator?

edit: Saya mem-fork generator dan mendorong komit pertama.

Jadi @harangue telah cukup banyak mengimplementasikan satu set besar definisi TypeScript Bulu yang sudah ada di https://Gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36 kita hanya perlu seseorang untuk meninjau dan berpotensi menyelesaikannya dan mengirimkannya ke dalam repositori definisi TypeScript.

Saya akan membuat ini bagian dari rilis Auk yang akan mendarat sebelum akhir tahun. Jika tidak ada yang melangkah sampai masalah ini akan ditutup untuk selamanya dan tidak akan ada dukungan TypeScript resmi atau diskusi lebih lanjut tentang ini selain permintaan tarik untuk semuanya.

Jika kualitasnya bagus, Anda harus mempertimbangkan untuk menggabungkan definisi dengan Feathers. Saya pikir banyak orang ingin menghindari penggunaan manajer paket sekunder sebanyak mungkin.

Mereka dapat diinstal melalui npm i @types/feathers . Anda tidak memerlukan hal-hal seperti typings lagi.

Saya pikir Anda baru saja menambahkannya ke https://github.com/DefinitelyTyped/DefinitelyTyped. Apa pun cara normal untuk melakukan ini. Jika kita menambahkannya ke repo inti, repositori plugin lain mungkin perlu ditambahkan definisi yang sesuai.

Dari FAQ yang Pasti Diketik:

Cabang types-2.0 secara otomatis dipublikasikan ke lingkup @types di NPM berkat types-publisher. Ini biasanya terjadi dalam waktu satu jam setelah perubahan digabungkan.

Tidak tahu itu. Jadi menambahkannya ke PastiTyped sudah cukup.

Ah, JS. Anda pergi selama satu atau dua bulan dan ekosistem berkembang :senyum:

Maaf bahwa ada keheningan radio tentang hal ini di pihak saya begitu lama. Saya baru saja merilis revisi inti lainnya hari ini yang memperbaiki beberapa masalah yang saya alami dengan pengetikan lama. Saya akhirnya dapat mulai bekerja dengan Feathers lagi di salah satu proyek saya, dan saya berharap dapat menambahkan pengetikan setidaknya untuk modul yang saya gunakan.

Definisi seperti yang ada di Inti siap untuk diserahkan ke Pasti Diketik kecuali untuk 1) tes pengetikan (hanya perlu menarik beberapa contoh dari dokumen Feathers) dan 2) anotasi Dokumen JS (yang akan bagus untuk intellisense, tetapi tidak esensial).

Secara teknis, pengetikan kail harus diekstraksi menjadi kail bulu juga. Namun, memperluas pengetikan di sini menjadi sedikit berantakan, karena uberproto memiliki beberapa pola mixin yang sedikit sulit untuk ditiru dengan tipe statis.

Senang Anda kembali @harangue. Saya pikir kita dapat meninggalkan pengetikan hook di sini untuk saat ini karena kita berencana untuk membuat hook sebagai bagian dari inti (lihat #408). Pengetikan juga mungkin perlu diperbarui dengan metode .hooks seperti yang dijelaskan di https://blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024 (belum didokumentasikan, sedang dikerjakan :).

@harangue kapan menurut Anda Anda akan mengirimkan jenis Anda untuk diketik dengan pasti?

Hai semuanya, sangat keren melihat defs TypeScript datang. @harangue , apa rekomendasi Anda untuk mengimpor bulu bersama dengan def di inti Anda? Mereka tidak mengekspor ruang nama yang cocok dengan perpustakaan feathers , jadi import ... from 'feathers' memunculkan kesalahan.

Hei @subvertallchris , Anda dapat menggunakan

import * as feathers from 'feathers';`

atau

import feathers = require('feathers');

mereka setara. :) Tepat ketika saya pikir saya mendapatkan waktu untuk Feathers lagi, saya terjebak dalam hal-hal lain, tetapi saya berharap definisi ini disempurnakan sepenuhnya pada tahun baru.

@j2L4e Garpu generator TS Anda sepertinya 404'ing ? Ada berita tentang ini? Juga, @harangue bagaimana feathers generate --ts untuk membuat cli bermain dengan TypeScript dengan baik atau dokumen. Biarkan aku tahu.

Sulit untuk mempertahankannya, bekerja dengan baik untuk mysql dan auth lokal saja dan generator-feathers akan segera usang. Jadi saya membuangnya.

Sangat menunggu rilis dari klien baru

Am 19. Dezember 2016 14:41:42 MEZ, schrieb georgeedwards [email protected] :

@j2L4e Garpu generator TS Anda sepertinya 404'ing ? Ada berita tentang ini?
Juga, @harangue bagaimana
tanah dan dengan senang hati membantu implementasi file definisi TS, a
garpu dengan bendera feathers generate --ts untuk membuat kli dimainkan
TypeScript dengan baik atau docs. Biarkan aku tahu.

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/feathersjs/feathers/issues/381#issuecomment -267966376

Apakah ada orang yang masih mengerjakan masalah ini? Saya sangat ingin menggunakan proyek ini dengan TypeScript

Halo semuanya

Saya senang untuk mengatakan: _Ini hampir selesai._
Saya telah membuat banyak garpu di FeatherjsOrg dan menulis definisi dengan repo. Dan Anda dapat melihat contoh ini menggunakan feathersjs dengan definisi TypeScript terbaik

Bulu + Nodejs + TypeScript
FeathersClient+Aurelia+TypeScript

[ya, ini mendukung ESNext, Commonjs, AMD dan modul global untuk potongan klien]

Sampel aurelia memberi Anda petunjuk bagaimana bekerja dengan angular2. Repositori ini memiliki banyak detail tentang bagaimana TypeScript dapat berguna untuk memberikan dokumentasi langsung tentang

Saya akan melakukan PR segera, tetapi Anda dapat melihat, membuat pertanyaan, dan memberi saya umpan balik. ?

Garpu dengan definisi:

• kait bulu
• bulu-primus
• bulu-socketio
• bulu-istirahat
• bulu-otentikasi-klien
• bulu-klien
• bulu

Saya punya sedikit pekerjaan, tapi saya suka bulu dan naskah

itu semua tautan relatif

Saya memperbaiki tautannya.

@AbraaoAlves Ini terlihat bagus, terima kasih! Saya baru saja akan menulis komentar cemberut dan menutup masalah dan saya senang Anda berkomentar terlebih dahulu Menantikan untuk melihat permintaan tarik!

Orang baik @AbraaoAlves !

@AbraaoAlves Saya hanya ingin mengucapkan terima kasih banyak, ini sangat membantu saya! Saya tidak percaya Anda datang pada saat terakhir

@AbraaoAlves Saya mengalami masalah sebenarnya menggunakan salah satu definisi Anda. Ketika saya menginstal paket-paket di package.json seperti

"feathers-errors": "^2.5.0",

"feathers-authentication": "^0.7.12",

"feathers-configuration": "^0.3.3",

"feathers": "https://[email protected]/AbraaoAlves/feathers.git#definition",

"feathers-hooks": "git://github.com/AbraaoAlves/feathers-hooks.git#definition",

"feathers-mongoose": "^3.6.2",

"feathers-rest": "git://github.com/AbraaoAlves/feathers-rest.git#definition",

"feathers-socketio": "git://github.com/AbraaoAlves/feathers-socketio.git#definition"`

Jadi ketika saya mencoba menggunakannya dalam file TypeScript seperti:

import * as feathers from "feathers"

itu melewati kompilasi tetapi tidak benar-benar berjalan dengan benar.

Mereka hanya menginstal definisi tipe dan bukan sumbernya. Tampaknya juga bahwa feathers-rest tidak mengekspor fungsi untuk TypeScript untuk dikenali
rest()' as a valid command for app.use(rest());

Juga satu masalah lagi, tampaknya app.use tidak lagi menerima argumen seperti
this.app.use(bodyParser.json());

dan harus digunakan sebagai

this.app.use(bodyParser.json() as any);

@Chrisdf Saya memperbaikinya dengan file tgz di package.json, kloning sekarang dan coba instal lagi.

Detail lebih lanjut tentang ini: masalah

@AbraaoAlves apakah ada alasan Anda tidak memberikan definisi pada PastiTyped? Dengan cara ini mereka akan tersedia melalui namespace @types dari NPM dan itu akan menghapus persyaratan bagi tim inti untuk menjaga agar definisi tetap mutakhir sebagai bagian dari rilis.

@AbraaoAlves Omong-omong, mengapa definisi tidak dilakukan tetapi malah diposting sebagai rilis tarball? Mereka akan lebih tersedia untuk typings dengan cara ini. Saya sangat menghargai upaya ini dan setuju bahwa akan bermanfaat untuk membawa definisi ke komunitas dalam bentuk yang dapat digunakan, PastiTyped akan menjadi langkah yang baik.

Saya telah menulis ulang pengetikan berdasarkan karya @AbraaoAlves dan @harangue. Saya akan segera mengirimkan pengetikan ini ke PastiTyped.

Dingin. Adakah yang bisa/harus kita lakukan untuk ini? Kalau tidak, saya berasumsi bahwa setelah hal-hal dimasukkan ke dalam PastiKetik, kita dapat menutup masalah ini?

harus disertakan dalam repositori ini dan package.json
(setidaknya itu akan menjadi kasus terbaik)

Contoh: package.json termasuk file

Halo semuanya o/
Terima kasih atas kesabaran dan masukannya.

@stevehipwell dan @daffl : Saya percaya pada file definisi

Saya tahu inisiatif @types dan DefinitlyTyped, dan ini penting untuk komunitas TypeScript tepat waktu sehingga orang-orang javascript tidak khawatir tentang definisi.

Hari ini, jika kami memiliki kesempatan untuk mempertahankan keduanya di satu tempat, di bawah satu rilis, kesalahan komunikasi akan memiliki insiden yang jauh lebih rendah dan kami akan memiliki definisi resmi berdasarkan rilis!

Contoh proyek javascript mempertahankan definisi Anda sendiri: Aurelia , Preact , ...

Jika semua orang setuju, berikut adalah tautan PullRequest:

• bulu
• bulu-otentikasi-klien
• kait bulu
• bulu-primus
• bulu-istirahat
• bulu-socketio
• bulu-otentikasi
• bulu-klien (saya akan mengirim setelah yang lain ini diselesaikan)

Masih banyak pekerjaan yang harus dilakukan, seperti tes mengetik, otomatisasi, ... tetapi ini baru permulaan.

TypeScript S2 FeathersJS!

Halo semua,

Saya setuju dengan @AbraaoAlves bahwa solusi ideal adalah memasukkan file definisi TypeScript dengan paket secara langsung, namun skenario terburuk adalah menyertakan file definisi yang akhirnya kedaluwarsa. Inilah mengapa saya menyarankan agar DefinitlyTyped digunakan untuk mempertahankan definisi sebagai solusi jalan tengah yang sesuai dengan mentalitas Node untuk memecah hal-hal kompleks menjadi komponen yang lebih kecil dan lebih mudah dikelola.

Untuk memastikan bahwa definisi tetap sinkron dengan rilis proyek, perlu ada transparansi yang lebih baik dari tim bulu. Sejauh ini saat menulis definisi saya sendiri, saya tidak yakin apa status rilis saat ini; blognya kurang update dan ada beberapa code name (v3, auk, buzzard??) yang tidak berarti apa-apa.

@AbraaoAlves - Definisi Anda terlihat bagus, tetapi dari apa yang saya lihat ada area yang hilang seperti metode hooks() . Apakah Anda tertarik untuk menambahkan ini?

Hai @stevehipwell ,

Terima kasih untuk umpan baliknya. Dan inilah jawaban saya tentang:

Namun, skenario terburuk termasuk file definisi yang akhirnya kedaluwarsa ...
Untuk memastikan bahwa definisi tetap sinkron dengan rilis proyek, perlu transparansi yang lebih baik dari tim bulu

Ya, masalah sinkronisasi adalah masalah nyata, tetapi dapat diperbaiki dengan tes.
Saya menyarankan untuk membuat tes dalam TypeScript: #508

Jika setuju atau tidak tentang solusi ini, ambil pendapat Anda di sana.

Saya sangat termotivasi untuk menjadikan feathersjs sebagai TypeScript friendly, tanpa perubahan yang mengganggu, tentu saja.
Kami memiliki lebih banyak pekerjaan yang harus dilakukan, seperti metode hooks() , tetapi sekarang kami dapat membangun ini bersama-sama.

Jika Anda melihat bug atau kehilangan definisi, buat masalah.

@AbraaoAlves sepertinya ada keinginan untuk memperbarui definisi dan saya dengan senang hati membantu. Saya berasumsi bahwa Anda ingin peningkatan bug pada repo utama untuk definisi yang hilang setelah permintaan penggabungan Anda selesai?

@stevehipwell Ya, itu intinya.

Apa masalah dengan jadwal rilis dan apa yang bisa kami lakukan untuk membuatnya lebih baik? Tonggak di sini masih kira-kira apa yang kami rencanakan:

• Rilis berikutnya adalah Auk yang merupakan kode lengkap dengan generator yang sedang diselesaikan dan dokumen yang diperbarui. Perubahan yang melanggar ada di bulu-otentikasi v1.0.0
• Rilis setelahnya adalah Buzzard yang akan menyertakan perubahan inti berikut (yang terkadang saya sebut sebagai v3 - dan mungkin seharusnya tidak ):
  
  
  
  • Independensi kerangka kerja (https://github.com/feathersjs/feathers/milestone/9) (dan dengan itu struktur terpadu untuk klien )
  
  
  • Kait di inti (https://github.com/feathersjs/feathers/issues/408)
  
  
  • Pemfilteran acara berbasis saluran (https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856)
  
  

Apa proses yang harus dilakukan untuk memperbarui definisi setelah fitur tersebut mendarat?

Definisi TypeScript seperti .h (header) di C++. Jika Anda memiliki header yang tidak merespons modul Anda, masalah dapat terjadi saat runtime, seperti dokumentasi yang tidak sesuai dengan versi kode yang digunakan.

Oleh karena itu, saya percaya bahwa definisi harus dimasukkan dalam setiap tonggak yang memerlukan perubahan dalam API, misalnya: memindahkan metode ke repositori lain atau menambahkan parameter baru ke metode, …

Saya akan mengubah definisi otentikasi bulu, menghapus kait ke proyek tertentu agar selaras dengan v1.0.
Pertanyaannya sekarang adalah: Haruskah definisi dimasukkan dalam versi FeathersJS saat ini?

@AbraaoAlves saya pikir begitu. Saya dapat membuat rilis kecil untuk semua PR Anda dan kami dapat mengulanginya dari sana. Satu-satunya hal yang saya masih bertanya-tanya adalah #508 tetapi saya akan mengomentari itu.

Saya menghadapi dua masalah dengan pengetikan di atas.

socketio tidak mau bekerja.

node_modules/feathers-socketio/index"' resolves to a non-module entity and cannot be imported using this construct.

Dan sisanya membutuhkan penangan meskipun feathers-cli Anda keluar tanpa argumen.

.configure(rest()) // Error disini mendeklarasikan function rest(handler:Function): Function;
.configure(socketio())

simpul -v
v6.6.0

npm -v
3.10.5

tsc -v
2.1.6

Akan menarik juga untuk menunjukkan bagaimana menggunakan "bulu ()" sebagai modul karena ini adalah titik masuk.
Saya bisa mengonversi semua layanan/middleware lain yang dihasilkan tetapi harus ada cara yang lebih baik yang merangkum bulu() dalam konstruktor() {}. (Saya baru mengenal bulu, saya mungkin melakukan kesalahan juga ...)

Bisakah kita mengeluarkan definisi sebagai rilis patch? Tingkat perubahan ini akan sangat cocok dengan rilis patch; tidak ada perubahan yang melanggar dan tidak ada fungsi baru. Bahkan pengetikan sebagian atau salah lebih baik daripada tidak ada pengetikan.

Setelah kami memiliki rilis maka kami memiliki titik awal kerja yang dapat kami gunakan augment untuk meningkatkan pengetikan.

Jika ini terus mandek dan harus menempuh rute PastiTyped untuk definisi saya. Saya tidak ingin harus melakukan ini dan dengan senang hati membantu dengan definisi dalam repo.

Saya punya pertanyaan untuk @AbraaoAlves di #508 tetapi belum mendapat balasan. Jika kami membuat rilis, kami membutuhkan seseorang yang tersedia untuk dengan cepat mengatasi masalah apa pun yang mungkin muncul (terutama karena kasus terburuknya mungkin merusak aplikasi yang ada yang menggunakan TypeScript). Bisakah kita berkoordinasi di Slack untuk waktu yang tepat untuk membuat dan memverifikasi rilis (kita bisa mulai dengan minor.pre)?

Dirilis dalam versi minor untuk setiap modul melalui

• https://github.com/feathersjs/feathers/pull/507
• https://github.com/feathersjs/feathers-authentication-client/pull/25
• https://github.com/feathersjs/feathers-hooks/pull/135
• https://github.com/feathersjs/feathers-primus/pull/43
• https://github.com/feathersjs/feathers-rest/pull/101
• https://github.com/feathersjs/feathers-socketio/pull/60
• https://github.com/feathersjs/feathers-authentication/pull/412

Pertama-tama, terima kasih kepada semua orang yang berpartisipasi dalam diskusi ini dan terutama kepada mereka yang berkontribusi. Kami memang merilis versi minor dengan definisi TypeScript untuk banyak repositori Feathers tetapi itu menyebabkan sejumlah masalah - dan rilis tidak terjadwal untuk modul yang cukup stabil, membuat pengguna memperbarui yang bahkan tidak menggunakan TypeScript sama sekali - tanpa cara untuk inti tim (di mana tidak ada yang menggunakan TypeScript) untuk memperbaikinya dengan andal.

Takeaway utama saya dari seluruh diskusi Feathers + TypeScript adalah tampaknya sangat sulit untuk membuat dan memelihara pengetikan untuk proyek JavaScript yang ada (bagi saya yang tidak berbicara dengan baik untuk klaim TypeScript interoperabilitas). Karena tim inti tidak menggunakan TypeScript, satu-satunya pilihan kami untuk bergerak maju saat merilis perubahan API yang melanggar adalah menghapus definisi TypeScript yang sudah ketinggalan zaman.

Ini akan menjadi besar untuk memiliki up-to-date definisi naskah untuk modul Feathers di DefinitelyTyped repositori dan kami akan melakukan segala yang kami bisa untuk membantu membuat itu terjadi, tetapi dengan waktu yang terbatas yang kami miliki kita tidak dapat menambahkan overhead mendukung dan memelihara sesuatu yang tidak kami gunakan secara pribadi di repositori kami sendiri.

bagi saya itu tidak berbicara dengan baik untuk klaim TypeScript interoperabilitas

Feathers dapat digunakan dengan sempurna tanpa pengetikan khusus, hanya JS biasa kemudian tanpa intellisense dan tipe. Terutama sistem plugin feathers dengan penggunaan mixin yang berat membuat pembuatan pengetikan menjadi sulit, karena itu adalah cara yang sangat non-typescripty dalam melakukan sesuatu. Saya adalah pengguna TypeScript biasa (dan penggemarnya), tetapi kembali ke ES6 untuk hal-hal bulu sisi server untuk saat ini.
Mempertahankan tipe secara terpisah tampaknya menjadi cara yang lebih cocok di sini tanpa seorang pun di tim inti yang benar-benar menggunakan TypeScript.

Feathers akan menjadi kerangka kerja sisi server yang disukai untuk Angular jika dimainkan dengan baik dengan TypeScript. Katakan saja :-). Aku pindah untuk saat ini.

@j2L4e Saya pikir ini akan lebih mudah untuk rilis berikutnya setelah sebagian besar hal yang sekarang dicampur oleh plugin akan menjadi bagian dari inti. Saya tidak yakin apakah itu akan menyelesaikan masalah umum untuk mendapatkan bantuan dengan andal dengan ini.

@rjsteinert Apa yang ada saat ini sebagian besar harus berfungsi tetapi ya, seperti halnya proyek sumber terbuka apa pun, Anda memiliki kesempatan untuk mencoba dan membantu atau melanjutkan.

Anda memiliki kesempatan untuk mencoba dan membantu atau melanjutkan.

Saya salah satu dari orang-orang yang baru mengenal Angular, programmer JS lama, menyadari betapa TS membuat hidup menjadi besar dan menyadari jika kita tidak berperan dengannya di sisi server, tim akan mengutuknya dan berfantasi tentang menulis ulang setiap hari selama beberapa tahun ke depan. Bagaimanapun, kita mungkin menggunakan bulu karena kurangnya pilihan dan dalam hal ini pasti membantu menjaga Pengetikan tetap mutakhir. Hanya mengatakan bahwa ketika kami lewat dan melihat "satu-satunya pilihan kami bergerak maju saat merilis perubahan API yang melanggar adalah menghapus definisi TypeScript yang sudah ketinggalan zaman", kami mencari di tempat lain. Jangan anggap remeh, saya mengerti kebutuhan untuk mendukung proyek yang ada, Anda semua tidak cukup beruntung (saya mungkin ditakdirkan) berada dalam situasi saya di mana kami melakukan penulisan ulang.

@rjsteinert apa yang ditawarkan TypeScript yang membuatnya sangat berharga bagi Anda? (pertanyaan jujur) Setelah kumpulan pekerjaan Feathers saya saat ini selesai, rasa ingin tahu saya hampir cukup terganggu oleh minat untuk melihat TypeScript, saya sendiri. Saya tahu ini membantu dengan pelengkapan otomatis/CodeSense, tetapi API Bulu sangat kecil sehingga saya tidak dapat membayangkannya berguna. Mohon maafkan ketidaktahuan saya. ;)

autocomplete/CodeSense adalah produk sampingan yang bagus tetapi saya biasanya menggunakan Vim jadi saya tidak mendapatkan barangnya. Pergeseran besar yang saya lihat sejauh ini adalah standarisasi tentang bagaimana Anda memperjelas cara menggunakan beberapa fungsi atau objek yang dikontribusikan. Melihat-lihat perpustakaan di NPM, saya menemukan banyak perpustakaan menggunakan solusi buatan sendiri dan kreatif mereka sendiri untuk memperjelas dan dapat digunakan apa yang tidak diberitahukan oleh bahasa yang diketik secara dinamis kepada Anda. TS menghemat banyak jenis pelat ketel untuk memeriksa sendiri saat Anda menulis kode dan membuatnya lebih mudah untuk memahami dengan cepat cara menggunakan kode orang lain. Hari-hari ini saya cenderung berpikir saya muak menulis boiler plate JS itu gaya saya sendiri dan saya benar-benar tidak ingin membaca README seseorang setiap kali saya menggunakan perpustakaan eksternal.

Saya setuju dengan @rjsteinert , saya telah bekerja dengan JavaScript selama 15+ tahun dan saya penggemar berat mengingat semua API. Saya bahkan biasa membuat kode dengan Notepad tanpa warna apa pun. Saya dulu bekerja dalam tim di Microsoft di mana seluruh situs ditulis dengan JavaScript saja. Saya dapat memberitahu Anda setelah situs Anda mencapai lebih dari 50 programmer, semuanya menjadi berantakan. Anda tidak hanya harus mengikuti lebih banyak konvensi, tetapi situs Anda mogok hanya saat runtime.

Jika Anda menulis di pos GitHub ini dan menggunakan FeatherJS, Anda mungkin adalah pengembang JavaScript yang rajin. Jika Anda adalah salah satu pengembang FeatherJS, Anda tidak akan melihat gunanya menggunakan TypeScript untuk diri Anda sendiri. Anda tidak memerlukan perkakas khusus, atau bantuan TypeScript. Anda adalah unicorn JavaScript.
Saya sangat menentang TypeScript (terutama karena kami terpaksa menggunakannya dengan versi Alpha 1.1), tetapi selama bertahun-tahun, saya telah belajar untuk menghargainya dan tidak dapat hidup tanpanya. Rekan-rekan yang akan bekerja dengan Anda tidak akan sepengetahuan Anda dalam JavaScript. Mereka akan datang dari semua latar belakang yang berbeda, dan akan mengutuk bagaimana JavaScript adalah omong kosong.

Bahasa TypeScript telah berkembang pesat dari umpan balik komunitas sejak saat itu.
Anda tidak dapat membangun situs web besar tanpa alat dan tim besar. Seperti yang dikatakan @rjsteinert , tim akan mulai menggunakan TypeScript untuk sisi klien, kemudian setelah beberapa saat, mereka akan sangat tidak senang menggunakan sisi server. Upaya akan dilakukan untuk mengubah infrastruktur agar sesuai dengan kebutuhan perusahaan mereka, kemudian featherjs akan dikesampingkan.

Lihat bahasa yang paling populer digunakan di web: PHP, NodeJS, Ruby, C#, Java... Beberapa dari mereka diketik, beberapa tidak. Saya bekerja dengan semua bahasa ini dan saya dapat memberi tahu Anda bahwa setelah bertahun-tahun, saya tidak ingin kembali ke bahasa "discover-error-at-runtime-only". Mereka semua memiliki pesona, pro dan kontra. Dalam tim besar, saya selalu menyarankan untuk menggunakan sesuatu yang sedikit lebih kuat dan diketik.

Contoh terbaru dari seseorang yang menggunakan PHP SDK yang saya tulis. Jika Anda memiliki metode yang menerima "angka besar" dengan 100 digit, Anda sebenarnya memperlakukannya sebagai string. Pengembang pemula akan membuka bug yang menanyakan mengapa saat memanggil setValue(123456789123...) tidak berfungsi, tampaknya crash cukup rendah di NodeJS atau dalam metode substr . Sekarang, pengembang perantara akan memeriksa dokumentasi Anda dan menemukan bahwa itu seharusnya berupa string. Bayangkan dengan mengetik, Anda memaksa string untuk dimasukkan saat Anda mengetik atau mengkompilasi. Maka pengembang tidak perlu membaca dokumentasi khusus atau membuka bug.

Saya meneliti sedikit kerangka kerja mana yang akan digunakan untuk proyek Angular2 + NodeJS baru saya, dan FeatherJS tampaknya hanya yang saya butuhkan. Namun, jika proyek server lain keluar hari ini dan berkata "Saya mendukung TypeScript secara resmi di luar kotak", saya akan langsung beralih.

Terima kasih atas masukan semua orang tentang masalah ini. Ada beberapa diskusi yang sangat bagus tetapi saya merasa bahwa itu mulai mengarah pada manfaat dari TypeScript dan bukan itu sebenarnya masalah ini. Tim inti telah membahas dan kami tidak akan mendukung definisi TypeScript karena mereka tidak penting untuk bekerja dengan Feathers dan akan mengurangi tingkat di mana kami dapat mengembangkan inti Feathers. Kami sudah memiliki banyak hal untuk diperbarui saat melakukan rilis. Kami mencoba mengurangi ketergantungan agar rilis lebih cepat, sedangkan menambahkan definisi TypeScript akan menambah lebih banyak pekerjaan. Karena tidak ada tim inti Feathers yang menggunakan TypeScript, kami:

1. tidak memiliki pengetahuan yang memadai untuk mempertahankan definisi dengan benar
2. tidak dapat menghabiskan waktu mengerjakan definisi ketika sebagian kecil dari basis pengguna kami "memerlukan" definisi tersebut. Kami memiliki banyak hal lain untuk dikerjakan yang berdampak pada lebih banyak orang.

Bagi mereka yang ingin membuat/mempertahankan definisi resmi, kami akan dengan senang hati menautkannya di bagian ekosistem dokumen baru, tetapi karena kami sendiri tidak menggunakannya dan definisi TS tidak diperlukan saat menggunakan Feathers dan lebih merupakan preferensi pribadi kita tidak akan memeliharanya. Kami akan menariknya dari repo yang ada dan @daffl akan memasukkannya ke https://github.com/feathersjs/feathers-typescript. Jika @jsgoupil , @rjsteinert , @AbraaoAlves atau siapa pun yang tertarik ingin mempertahankan repo, kami akan dengan senang hati memberikan akses dan/atau mentransfer repo. Kami pikir ini akan membuatnya lebih mudah untuk menjaga agar definisi tetap terbaru dan lebih mudah untuk dikirim ke PastiTyped (sebenarnya saya tidak tahu banyak tentang proses itu).

Kami akan membiarkan masalah ini terbuka untuk diskusi tetapi akan mengunci utas jika terus membahas manfaat TypeScript sebagai lawan dari apa yang perlu dilakukan untuk mengimplementasikan definisi di luar repo inti. 😄

jika Anda tidak ingin memasukkan ini, dapatkah Anda menyertakan direktori sumber dalam versi yang diterbitkan ke npm dan mengatur jsnext:main atau module di package.json ke entri

Karena TypeScript mendukung definisi modul wildcard sekarang, ini akan menjadi solusi yang mudah untuk menghapus semua pengetikan dari bulu-sub-modul dan memasukkan ini ke dalam feathers :

declare module 'feathers';
declare module 'feathers-*';

yang akan mendeklarasikan bulu dan semua modul bulu-apa pun sebagai tipe any , yang setidaknya "membuatnya berfungsi" dengan TS out-of-the-box. Anda tidak mendapatkan intellisense yang ditingkatkan tetapi itu hanya berfungsi tanpa merusak barang-barang di proyek yang ada dan menghilangkan masalah dari punggung orang.

Saya juga melakukan:

"paths": {
            "feathers-socketio": ["typedefs/feathers-socketio/index.d.ts"]

untuk "mengganti" pengetikan yang salah atau tidak lengkap untuk sementara, daripada membuka banyak PR kecil dan membuat banyak versi tambalan yang sebenarnya tidak menambal apa pun untuk pengguna non-TS.

Hai,
Saya hanya ingin mengklarifikasi satu keraguan tentang dukungan TypeScript.
Sesuai dengan definisi jenis Service , semua metode layanan adalah metode yang diperlukan.

Tetapi menurut dokumentasi, metode layanan adalah opsional.
Melihat

Jadi, definisi layanan harus seperti di bawah ini bukan?

  interface Service<T> extends events.EventEmitter {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
    setup?(app?: Application, path?: string): void;
  }

@harish2704 ya itu benar

Saya tetap menggunakan solusi "override repo typedefs" saya untuk saat ini, dan mungkin suatu hari nanti (hehe semoga) menerbitkan pada feathers-typescript atau PastiTyped, setelah saya selesai dengan proyek saya.

Itu memastikan bahwa saya akan mengirimkan beberapa definisi yang telah teruji pertempuran pada setidaknya satu proyek produksi.

Terima kasih Co!

Pada Sel, 9 Mei 2017 jam 07.42, Richard Michael Coo <
[email protected]> menulis:

@harish2704 https://github.com/harish2704 ya itu benar

Saya tetap menggunakan solusi "override repo typedefs" saya untuk saat ini, dan
mungkin suatu hari nanti (hehe semoga) terbitkan di feathers-typescript or
Pasti Diketik, setelah saya selesai dengan proyek saya.

Itu memastikan bahwa saya akan mengirimkan beberapa definisi yang telah teruji pertempuran di
setidaknya satu proyek produksi.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
.

@myknbani
Mungkin sedikit lebih awal untuk check-in - tetapi bagaimana Anda bisa melanjutkan dengan typedefs? Apakah Anda membutuhkan tangan sama sekali? :) Saya ingin menggunakan bulu dalam proyek baru, tetapi kurangnya dukungan TypeScript adalah sedikit masalah.

kurangnya dukungan TypeScript

Tidak yakin apa yang Anda maksud dengan tepat. Itu benar-benar bekerja. Ini jauh dari sempurna, tetapi berhasil.

@jonlambert Saya setuju dengan @j2L4e. Yang sudah ada tidak sempurna, tapi saya hanya melakukan trik yang saya sebutkan di sini untuk apa pun yang tidak typecheck.

IMHO, paket seperti feathers-rest yang hanya perlu digunakan dalam sekitar dua baris tidak layak untuk diketik sama sekali :-)

Saya bahkan tidak ingat apa yang saya ubah, tetapi saya pikir tidak ada masalah menggunakan kait dan layanan.

@j2L4e maksud saya feathers tidak mendukung TypeScript. Anda benar, mungkin untuk menggunakannya bersama-sama dengan solusi yang Anda sebutkan di atas, tetapi tentu saja tidak 'didukung' seperti yang dapat kita lihat dalam masalah ini!

TypeScript merupakan bagian integral dari alur kerja kami dalam memastikan aplikasi kami dapat dipelihara di telepon, jadi saya pikir perlu memeriksa untuk melihat apakah definisi @myknbani tersedia. Jangan khawatir! 🙂

Ia bekerja tanpa solusi itu juga. Ada pengetikan yang tersedia di repo resmi yang tidak perlu terlalu banyak mengutak-atik. Jangan tersinggung, tetapi menurut saya Anda bahkan tidak mencoba jika itu berhasil.

Karena tidak ada tim inti Feathers yang menggunakan TypeScript, kami:

1. tidak memiliki pengetahuan yang memadai untuk mempertahankan definisi dengan benar
2. tidak dapat menghabiskan waktu mengerjakan definisi ketika sebagian kecil dari basis pengguna kami "memerlukan" definisi tersebut. Kami memiliki banyak hal lain untuk dikerjakan yang berdampak pada lebih banyak orang.

Sebagai pendatang baru di framework saya akan mengira dengan adanya isu ini, ditambah lagi komentar-komentar di atas sudah cukup menganggap kurangnya dukungan TS. Maaf jika itu kesimpulan yang salah, saya pasti akan mencobanya.

Juga, itu mungkin "berfungsi", tetapi tanpa jaminan apa pun untuk memastikan definisi tipe tetap up to date dengan API, sepertinya itu berpotensi menyebabkan masalah di masa depan.

Kamu benar.

Namun, ada beberapa peningkatan akhir-akhir ini dan penyelesaian pengetikan direncanakan dan sedang dibuat.

Itu berita bagus Sangat menikmati bekerja dengan framework sejauh ini dan saya senang dapat menggunakannya dengan TS

Ia bekerja tanpa solusi itu juga. Ada pengetikan yang tersedia di repo resmi yang tidak perlu terlalu banyak mengutak-atik. Jangan tersinggung, tetapi menurut saya Anda bahkan tidak mencoba jika itu berhasil.

@j2L4e Anda benar. Saya pikir typedefs berada dalam kondisi yang jauh lebih baik sekarang. Saya menghapus semua "penggantian" saya dan satu-satunya masalah yang tersisa sejauh ini adalah ! pernyataan (karena strictNullChecks ) saat menggunakan app.service(...) .

Saya akan menyarankan memisahkan pengetikan untuk definisi layanan (di mana metode layanan semuanya opsional) dan contoh layanan (di mana semua metode layanan tidak terdefinisi). Saat ini, saya harus dengan susah payah menambahkan ! s di mana-mana misalnya await app.service('api/foos').create!([{

Saya memiliki ini dalam solusi saya:

interface ServiceDefinition<T> {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
    setup?(app?: Application, path?: string): void;
  }

  interface ServiceInstance<T> extends events.EventEmitter {
    find(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get(id: number | string, params?: Params, callback?: any): Promise<T>;
    create(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

Bagaimana dengan ini:

  interface GetMethod<T>{
    /**
     * Retrieves a list of all resources from the service.
     * Provider parameters will be passed as params.query
     */
    find(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
  }

  interface FindMethod<T>{
    /**
     * Retrieves a single resource with the given id from the service.
     */
    get(id: number | string, params?: Params, callback?: any): Promise<T>;
  }

  interface CreateMethod<T>{
    /**
     * Creates a new resource with data.
     */
    create(data: T[], params?: Params, callback?: any): Promise<T[]>;
    create(data: T, params?: Params, callback?: any): Promise<T>;
  }

  interface UpdateMethod<T>{
    /**
     * Replaces the resource identified by id with data.
     * Update multiples resources with id equal `null`
     */
    update(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
  }

  interface PatchMethod<T>{
    /**
     * Merges the existing data of the resource identified by id with the new data.
     * Implement patch additionally to update if you want to separate between partial and full updates and support the PATCH HTTP method.
     * Patch multiples resources with id equal `null`
     */
    patch(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
  }

  interface RemoveMethod<T>{
    /**
     * Removes the resource with id.
     * Delete multiple resources with id equal `null`
     */
    remove(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

  interface OptionalMethods <T> {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T[], params?: Params, callback?: any): Promise<T[]>;
    create?(data: T, params?: Params, callback?: any): Promise<T>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

  type GetService<T> = GetMethod<T> & ServiceAddons;
  type FindService<T> = FindMethod<T> & ServiceAddons;
  type CreateService<T> = CreateMethod<T> & ServiceAddons;
  type UpdateService<T> = UpdateMethod<T> & ServiceAddons;
  type PatchService<T> = PatchMethod<T> & ServiceAddons;
  type RemoveService<T> = RemoveMethod<T> & ServiceAddons;

  interface ServiceCore<T> extends OptionalMethods<T> {
    setup?(app?: Application<any>, path?: string): void;
  }

  interface ServiceAddons extends events.EventEmitter {
    filter(any?: any): this;
  }

  type Service<T> = OptionalMethods<T> & ServiceAddons;

Ini memungkinkan Anda mengetik layanan non-TS apa pun dengan membuat tipe baru, misalnya untuk feathers-mailer:

type MailerService = CreateService<Mail>;

Atau layanan (sangat tidak berguna) yang hanya dapat membuat dan menghapus:

type TrashyService<T> = CreateService<T> & RemoveService<T>;

Ini semua dengan menggunakan fungsi pemilih untuk mendapatkan layanan dalam pikiran (misalnya app.service(s => s.mailout)) akan mengembalikan layanan itu dengan jenis yang sesuai. Seperti yang terlihat di sini:

Hanya memeriksa kembali, bagaimana kita mendapatkan? @j2L4e posting ^ terlihat sangat rapi! Hanya ingin tahu apa lagi yang perlu dilakukan untuk melihat apakah saya dapat membantu.

Oke, kesalahan yang saya lihat sejauh ini:

import * as handler from 'feathers-errors/handler';
import * as notFound from 'feathers-errors/not-found'; //[1]

app.use(notFound()); //[2]
app.use(handler()); //[3]

[1]

[ts] Modul '"c:/Users/George/Source/Repos/ts4/node_modules/feathers-errors/not-found"' diselesaikan ke entitas non-modul dan tidak dapat diimpor menggunakan konstruksi ini.

[2]

Argumen tipe 'Function' tidak dapat ditetapkan ke parameter tipe 'PathParams'.
Ketik 'Fungsi' tidak dapat ditetapkan untuk mengetik '(string | RegExp)[]'.
Properti 'push' tidak ada dalam jenis 'Fungsi'.

[3]

Argumen tipe 'Function' tidak dapat ditetapkan ke parameter tipe 'PathParams'.
Ketik 'Fungsi' tidak dapat ditetapkan untuk mengetik '(string | RegExp)[]'.
(alias) notFound(): Fungsi

Apakah ada solusi yang ada?

https://github.com/feathersjs/feathers-errors/pull/87

Untuk versi berikutnya, @j2L4e telah melakukan beberapa pekerjaan bagus untuk menyempurnakan pengetikan. Berikut adalah langkah-langkah untuk mencobanya dan uji beta:

npm i -g lerna
git clone -b buzzard-j2L4e  https://github.com/feathersjs-ecosystem/feathers-typescript.git
cd feathers-typescript
lerna bootstrap

lerna akan menautkan semua paket dan deps untuk Anda. Sekarang buka subfolder ./packages/tests (di mana belum ada tes yang dapat ditemukan, jadi saya menjadikannya semacam taman bermain) dan coba kebaikan TS! Lihat index.ts.

Untuk mengkompilasi dan menjalankan, jalankan npm start dari ./packages/tests

Baru saja memulai migrasi dari Feathers 2 ke 3, file index.d.ts sekarang hilang dari paket head @feathersjs . Ada rencana untuk memulihkannya?

Seperti disebutkan satu komentar di atas, mereka telah dipindahkan ke https://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4e untuk dikirimkan ke PastiTyped. @j2L4e terlalu sibuk sekarang jadi terserah orang lain untuk mengambil ini. Dari apa yang saya pahami, sebagian besar mendapatkan Linting lewat dan mengirimkannya ke PastiTyped. Saya akan dengan senang hati membantu siapa pun yang bersedia mengambil ini tetapi tidak memiliki rencana untuk mengambilnya sendiri.

Ya, itu lebih banyak pekerjaan daripada yang saya perkirakan dan umpan balik dari komunitas hampir nol. Saya akan mewujudkannya segera setelah saya menemukan waktu. Namun, tidak terlalu cepat.

jika ada yang mau berpadu di sini, itu akan sangat luar biasa. Ini semua tentang DT linting sekarang, selain semuanya bekerja dengan baik

salin dan tempel cepat dari slack:

teman-teman, saya benar-benar sangat sibuk saat ini, jadi pengetikan bukanlah prioritas utama. mereka bekerja tetapi PastiTyped cukup ketat dalam hal aturan linting. jika Anda dapat membantu membuat pengetikan melewati proses linting yang pasti diketik, itu akan luar biasa

lihat garpu DT saya di sini https://github.com/j2L4e/definitelytyped , Anda akan menemukan paket feathersjs di types/feathersjs__packagename

clone, npm install dan jalankan linter pada salah satu paket, misal npm run lint @feathersjs/feathers (diedit)

@feathersjs/feathers sudah linting dengan baik, jadi Anda bisa menggunakannya sebagai referensi. (diedit)

Definisi TypeScript sedang menunggu tinjauan untuk ditambahkan ke PastiTyped di https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22805

Definisi sekarang dapat diakses melalui NPM!

Ya, instal @types/feathersjs__package untuk paket @feathersjs/package dan berikan umpan balik!

@erikma terima kasih atas dukungan Anda!

@j2L4e Terima kasih atas pekerjaan Anda! Tetapi apakah Anda yakin telah mengekspor semua fungsi @featherjs/express ? Saya tidak dapat menemukan penyebutan rest, json, notFound, dan urlencoded dalam file definisi TypeScript Anda.

Anda benar, itu hilang.

tambahkan file Typings.d.ts untuk saat ini dengan:

import { ErrorRequestHandler, RequestHandler } from 'express';

declare module '@feathersjs/express' {
    export function errorHandler(options?: any): ErrorRequestHandler;
    export function notFound(): RequestHandler;
    export const rest: {
        (): () => void;
        formatter: RequestHandler;
    };
}

tidak tahu di mana urlencoded harus pergi.

urlencoded dan json telah ditambahkan ke express dalam versi minor terakhir. Apakah pengetikan express belum diperbarui?

Itu express atau feathersjs/express?

Itu baru saja diekspor kembali dari Express:

• https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/express/index.d.ts#L31
• https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/express/index.d.ts#L42

Jadi Anda harus dapat melakukan Import { urlencoded, json } from '@feathersjs/express' ? Atau apakah Anda akan mendapatkannya dari original diekspor?

Segala sesuatu yang diekspor dari require('express') diekspor kembali oleh @feathersjs/express : https://github.com/feathersjs/express/blob/master/lib/index.js#L82

Juga, apakah Anda tahu bagaimana menangani channels.ts dengan definisi yang baik-baik saja?
Saya minta maaf untuk melemparkan semua masalah pada Anda dalam waktu yang singkat.

Impor @types/feathersjs__socket-commons

Impor? saya tidak mengerti

Maaf itu seharusnya mengatakan 'Impor @feathersjs/socket-commons'. Anda perlu menginstal jenisnya.

Jika saya menginstal @types/feathersjs__feathers app.channel tidak berfungsi. Jika saya kemudian menambahkan @types/feathersjs__socket-commons app.on berhenti bekerja.

akan diperbaiki melalui PastiTyped/DefinitelyTyped#23195

silakan ambil masalah lebih lanjut di sini: https://github.com/feathersjs-ecosystem/feathers-typescript/issues

Pelacakan masalah untuk definisi TS agak membingungkan. Anda mengarahkan orang-orang ke repo feathers-typescript tetapi Anda menyebutkan _"Repo ini sekarang sudah usang"_. Jika Anda tidak akan mempertahankan definisi di masing-masing repo dan sebagai gantinya menggunakan DT, saya pikir akan lebih masuk akal untuk menyimpan masalah di repo DT juga, karena mungkin di situlah PR akan berasal dan digabungkan.

Saya pikir kami memutuskan untuk mencobanya di sini. Saya telah mendapatkan permintaan melalui beberapa saluran, dan mengarahkan orang untuk pergi ke sana Adalah cara cepat untuk memusatkan itu. Secara pribadi, saya tidak terlalu peduli kemana perginya selama itu satu tempat

Apakah ada alasan mengapa kita tidak dapat menggunakan feathers.services.dogs daripada feathers.service('dogs') ?

Ya. feathers.service('dogs') memanggil defaultService (yang memberikan layanan pada klien) dan menghapus garis miring dari nama layanan.

Definisi naskah sekarang di DefinitelyTyped .

Silakan arahkan masalah dan pertanyaan apa pun ke https://github.com/feathersjs-ecosystem/feathers-typescript/issues