أوه ، لقد رأيت للتو https: //github.com/feathersjs/feathers/issues/64 ... لكن ربما اترك هذا مفتوحًا؟ لذلك بعض الناس سيقدمون المساعدة؟

أفضل طريقة للمضي قدمًا هي بدء مستودع مع بعض التعريفات الأساسية للطباعة (في # 64 ، قمت بنشر بعض المؤشرات حول مكان البدء) والمتابعة
مناقشة هناك.

يمكنني ترك هذه المشكلة مفتوحة لمدة شهر أو شهرين آخرين ، لكن الإصدار الآخر ظل مفتوحًا لمدة عام تقريبًا ولم يقم أحد باستلامه. كما هو مذكور هناك ، لا يستخدم الفريق الأساسي الحالي كتابًا مطبوعًا أو Angular ، لذا فهو ليس على رادارنا (ونفضل إبقاء المشكلات مفتوحة فقط إذا كانت هناك فرصة لمعالجتها في المستقبل المنظور).

أعتقد أن harangue كان يعمل على بعض التعريفات الأساسية. ربما يمكننا نقل المناقشة التي أجريناها على Slack حول المكان الذي سيعيشون فيه هنا؟

بالتأكيد! إذا دعت الحاجة إلى إغلاق هذه المشكلة ، فما عليك سوى المضي قدمًا.

سيكون من الرائع حقًا دعم الكتابة المطبوعة .. كيف يمكنني المساعدة؟

rollymaduk لقد أحرزت بعض التقدم اللائق في تعريفات Feathers ، لكننا لم نحدد بعد أفضل طريقة لتوزيعها (والأشياء انتقالية قليلاً مع TypeScript 2 على وشك إصدارها). إذا كنت ترغب في الحصول على شيء ما للعمل به حتى ذلك الحين ، فيمكنك رؤية هذا الجوهر الذي عملت عليه.

harangue عمل رائع حقًا يبدو جاهزًا تمامًا .. أعتقد أن بعض المناطق التي قد تتطلب بعض الاهتمام ستكون دمج بعض المكونات الإضافية الأساسية مثل المصادقة ومقدمي الخدمة (rest ، socke.io ، primus) وبعض محولات db ، أليس كذلك؟ من فضلك ماذا تقصد بأفضل طريقة لتوزيعها؟

لست متأكدًا مما إذا كنا قد ناقشنا هذا الأمر حتى الآن ، لكنني أعتقد أنه سيكون على ما يرام إذا قمنا بتوزيع تعريفات الطباعة في المستودع الرئيسي طالما كان هناك شخص ما للحفاظ عليها وتحديثها باستمرار. لذا بمجرد أن يصبحوا جاهزين ، يمكننا جعله جزءًا من إصدار Feathers 2.1 (والذي أعتقد أنه قد يتم شحنه أيضًا مع بعض التحذيرات ، على سبيل المثال ، سيتم إهمال عمليات الاسترجاعات في الخدمات في الإصدار 3).

هل هناك أي مفترق generator-feathers لـ TypeScript؟ هل أنت مهتم بالعمل على شوكة TS للمولد؟

تحرير: تفرعت المولد ودفعت الالتزام الأول.

لذا فقد نفذharangue إلى حد كبير مجموعة كبيرة من تعريفات Feathers Typescript الموجودة بالفعل في https://gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36 نحن فقط بحاجة إلى شخص ما لمراجعتها وربما الانتهاء منها وإرسالها إلى مستودع تعريفات TypeScript.

سأقوم بهذا الجزء من إطلاق سراح Auk الذي سيهبط قبل نهاية العام. إذا لم يتقدم أحد حتى ذلك الحين ، فسيتم إغلاق هذه المشكلة نهائيًا ولن يكون هناك دعم رسمي لـ TypeScript أو مزيد من المناقشة حول هذا الأمر بخلاف طلب السحب لكل شيء.

إذا كانت جودتها جيدة ، يجب أن تفكر في تجميع التعريفات مع الريش. أعتقد أن الكثير من الناس يرغبون في تجنب استخدام مدير حزمة ثانوي قدر الإمكان.

يمكن تثبيتها عبر npm i @types/feathers . لا تحتاج إلى أشياء مثل typings بعد الآن.

اعتقدت أنك أضفتها فقط إلى https://github.com/DefinitelyTyped/DefinitelyTyped. مهما كانت الطريقة العادية للقيام بذلك. إذا أضفناها إلى الريبو الأساسي ، فربما تحتاج مستودعات المكونات الإضافية الأخرى إلى إضافة تعريفات وفقًا لذلك.

من الأسئلة الشائعة من DefinitelyTyped:

يتم نشر فرع type -2.0 تلقائيًا في نطاق type -publisher. يحدث هذا عادةً في غضون ساعة من دمج التغييرات.

لم أكن أعرف ذلك. لذا فإن إضافتها إلى DefinitelyTyped سيكون كافياً.

آه ، شبيبة. لقد ذهبت لمدة شهر أو شهرين ويتطور النظام البيئي: ابتسم:

آسف أنه كان هناك صمت إذاعي حول هذا من نهايتي لفترة طويلة. لقد أصدرت للتو

التعريف كما هو موجود في الجوهر جاهز لتقديمه إلى "مكتوب بشكل مؤكد" باستثناء 1) اختبارات الكتابة (تحتاج فقط إلى سحب بعض الأمثلة من مستندات Feathers) و 2) تعليقات JS Doc (التي ستكون رائعة للتحدث ، ولكنها غير اساسي).

من الناحية الفنية ، يجب استخراج أنواع الخطاف إلى خطافات الريش أيضًا. يصبح توسيع الكتابة هنا فوضويًا بعض الشيء ، حيث أن uberproto يحتوي على بعض أنماط mixin التي يصعب نسخها مع الأنواع الثابتة.

من الجيد أن تعودharangue. أعتقد أنه يمكننا ترك كتابة الخطافات هنا في الوقت الحالي لأننا نخطط لجعل الخطافات جزءًا من النواة (انظر # 408). قد تحتاج أيضًا إلى تحديث الكتابة بالطريقة الجديدة .hooks كما هو موضح في https://blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024 (لم يتم توثيقها بعد ، والعمل عليها :).

harangue متى تعتقد أنك سترسل

مرحبًا بالجميع ، من الرائع حقًا رؤية مواضع TypeScript Defs. harangue ، ما feathers ، لذا فإن import ... from 'feathers' يظهر خطأ.

مرحبًا subvertallchris ، يمكنك استخدام

import * as feathers from 'feathers';`

أو

import feathers = require('feathers');

انهم متكافئين. :) فقط عندما اعتقدت أنني سأحصل على وقت للريش مرة أخرى ، علقت في أشياء أخرى ، لكنني آمل أن يتم توضيح هذه التعريفات بالكامل بحلول العام الجديد.

@ j2L4e يبدو أن شوكة مولد TS لديك 404'ing؟ أي أخبار عن هذا؟ أيضًا ، harangue كيف حالك؟ أنا حريص حقًا على رؤية هذه الأرض ويسعدني المساعدة في تنفيذ ملفات تعريف TS ، وهي شوكة بعلامة feathers generate --ts لجعل cli يلعب مع الكتابة بشكل جيد أو المستندات. دعني أعلم.

كان من الصعب الحفاظ عليها ، وعملت بشكل صحيح من أجل mysql والمصادقة المحلية فقط وستتقادم الريش المولد قريبًا على أي حال. لذلك ألغيت ذلك.

تنتظر بفارغ الصبر إطلاق CLI الجديد

صباح 19. ديسمبر 2016 14:41:42 MEZ ، schrieb georgeedwards [email protected] :

@ j2L4e يبدو أن شوكة مولد TS لديك 404'ing؟ أي أخبار عن هذا؟
أيضًا ، harangue كيف حالك؟ أنا حقا حريص على رؤية هذا
land ويسعدني المساعدة في تنفيذ ملفات تعريف TS ، أ
fork بعلم feathers generate --ts لجعل cli يلعب به
مطبوعا بشكل جيد أو المستندات. دعني أعلم.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/feathersjs/feathers/issues/381#issuecomment -267966376

هل لا يزال هناك أي شخص يعمل على هذه القضية؟ أرغب بشدة في استخدام هذا المشروع مع Typescript

أهلا بالجميع

يسعدني أن أقول: _ لقد أوشكت على الانتهاء ._ 😄
لقد صنعت العديد من الشوكات في FeatherjsOrg وأكتب التعريفات عن طريق الريبو. ويمكنك أن ترى هذه العينات باستخدام feathersjs مع أفضل التعريفات المطبوعة

الريش + Nodejs + الرواية
FeathersClient + Aurelia + Typescript

[نعم ، إنه يدعم ESNext و Commonjs و AMD والوحدات النمطية العالمية لأجزاء العميل]

تمنحك عينة aurelia أدلة على كيفية التعامل مع angular2. تحتوي هذه المستودعات على العديد من التفاصيل حول كيف يمكن أن تكون الكتابة المطبوعة مفيدة لتقديم توثيق حي حول

سأقوم بعمل العلاقات العامة قريبًا ، ولكن يمكنك أن ترى وتطرح لي الأسئلة وتعطيني تعليقات. 👌؟

تعريفات الشوكة:

• خطاف الريش
• الريش بريموس
• ريش مقبس
• ريش الراحة
• الريش-المصادقة-العميل
• الريش العميل
• الريش

كان لدي القليل من العمل ، لكني أحب الريش والطباعة

هذا كل شيء روابط ذات صلة

أصلحت الروابط.

AbraaoAlves هذا يبدو رائعا ، شكرا لك! كنت على وشك كتابة تعليق سخيف وإغلاق المشكلة ويسعدني أنك علقت أولاً 😉 أتطلع إلى رؤية طلبات السحب!

يا رجل طيبAbraaoAlves !

AbraaoAlves أردت فقط أن أقول شكرًا جزيلاً ، هذه مساعدة كبيرة بالنسبة لي! لا أصدق أنك أتيت في آخر لحظة

AbraaoAlves أواجه مشكلة بالفعل في استخدام أي من

"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"`

لذلك عندما أحاول استخدامه في ملف TypeScript مثل:

import * as feathers from "feathers"

يمر التجميع ولكن لا يعمل بشكل صحيح في الواقع.

يقومون فقط بتثبيت تعريفات النوع وليس المصدر. يبدو أيضًا أن Feathers-rest لا يصدر دالة ليتم التعرف عليها من خلال الكتابة المطبوعة
rest()' as a valid command for app.use(rest());

هناك أيضًا مشكلة أخرى ، يبدو أن app.use لم يعد يقبل الحجج مثل
this.app.use(bodyParser.json());

ويجب استخدامه كـ

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

Chrisdf أصلحت هذا مع ملفات

مزيد من التفاصيل حول هذا: القضية

AbraaoAlves هل هناك سبب لعدم وضع التعريفات على DefinitelyTyped؟ بهذه الطريقة ستكون متاحة من خلال types namespace من NPM

AbraaoAlves بالمناسبة ، لماذا لم يتم الالتزام بالتعريفات ولكن بدلاً من ذلك تم نشرها كإصدار tarball؟ ستكون متاحة أكثر مقابل typings بهذه الطريقة. أنا أقدر بشدة هذا الجهد وأوافق على أنه سيكون من المفيد تقديم التعريفات إلى المجتمع في شكل قابل للاستخدام ، بالتأكيد ستكون الكتابة خطوة جيدة.

لقد أعدت كتابة المطبوعات بناءً على أعمال AbraaoAlves وharangue. سأرسل هذه الأنواع إلى DefinitelyTyped قريبًا.

رائع. أي شيء يمكننا / ينبغي القيام به من أجل هذا؟ وإلا أفترض أنه بمجرد تضمين الأشياء في DefinitelyTyped ، يمكننا إغلاق هذه المشكلة؟

في هذا المستودع و package.json
(على الأقل هذا سيكون أفضل حال)

مثال: ملف package.json مضمّن

مرحبا بالجميع يا /
شكرا على الصبر وردود الفعل.

stevehipwell و daffl : أعتقد أن ملف التعريفات

أعرف مبادرة types و DefinitlyTyped ، وهذا مهم لمجتمع

اليوم ، إذا أتيحت لنا الفرصة للحفاظ على كليهما في مكان واحد ، في ظل إصدار واحد ، فستكون أخطاء الاتصالات أقل بكثير وسيكون لدينا تعريفات المسؤولين عن طريق الإصدار!

أمثلة على مشاريع جافا سكريبت تحتفظ بتعريفاتك الخاصة: Aurelia ، Preact ، ...

إذا وافق الجميع ، فإليك روابط PullRequest:

• الريش
• الريش-المصادقة-العميل
• خطاف الريش
• الريش بريموس
• ريش الراحة
• ريش مقبس
• مصادقة الريش
• عميل الريش (سأرسل بعد حل هؤلاء الآخرين)

هناك الكثير من العمل الذي يجب القيام به ، مثل الاختبارات المكتوبة ، والأتمتة ، ... لكن هذه مجرد بداية.

ريش مطبوع S2 ، JS!

أهلا بكم،

أتفق مع AbraaoAlves على أن الحل المثالي هو تضمين ملفات تعريف TypeScript مع الحزم مباشرةً ، ولكن أسوأ سيناريو هو تضمين ملفات التعريف التي تنتهي صلاحيتها. هذا هو السبب في أنني كنت أقترح استخدام DefinitlyTyped للحفاظ على التعريفات كحل وسط يتماشى مع عقلية العقدة المتمثلة في تقسيم الأشياء المعقدة إلى مكونات أصغر وأسهل في الإدارة.

للتأكد من أن التعريفات تظل متزامنة مع إصدارات المشروع ، يجب أن يكون هناك شفافية أفضل من فريق الريش. حتى الآن أثناء كتابة التعريفات الخاصة بي ، لست متأكدًا من الوضع الحالي للإصدار ؛ لا يتم تحديث المدونة ، وهناك عدد من أسماء الرموز (v3 ، auk ، buzzard ؟؟) لا تعني شيئًا.

AbraaoAlves - تبدو التعريفات الخاصة بك جيدة ، ولكن مما يمكنني رؤيته هناك مناطق مفقودة مثل الطرق hooks() . هل أنت مهتم بإضافة هذه في؟

مرحبًا stevehipwell ،

شكرا على ملاحظاتك. وإليك إجاباتي عن:

ومع ذلك ، فإن أسوأ سيناريو يتم تضمينه في ملفات التعريف التي ينتهي بها الأمر لتصبح قديمة ...
للتأكد من أن التعريفات تظل متزامنة مع إصدارات المشروع ، يجب أن يكون هناك شفافية أفضل من فريق الريش

نعم ، مشكلة المزامنة مشكلة حقيقية ، ولكن يمكن إصلاحها بالاختبارات.
أقترح إجراء اختبارات بخط مطبوع: # 508

إذا كنت توافق أو لا توافق على هذا الحل خذ رأيك هناك.

أنا متحمس حقًا لجعل feathersjs صديقة للطباعة ، دون تغييرات مزعجة ، بالطبع.
لدينا الكثير من العمل الذي يتعين علينا القيام به ، مثل طرق hooks() ، لكن يمكننا الآن بناء هذا معًا.

إذا رأيت خطأً أو فاتك تعريف ما ، فقم بإحداث مشكلة.

AbraaoAlves يبدو أن هناك رغبة في تحديث التعريفات وأنا أكثر من سعيد للمساعدة. أفترض أنك تريد رفع الأخطاء في مستودعات إعادة الشراء الرئيسية للتعريفات المفقودة بمجرد اكتمال طلبات الدمج؟

stevehipwell نعم ، هذا هو الهدف.

ما المشكلة في جدول الإصدار وما الذي يمكننا فعله لتحسين ذلك؟ لا تزال المعالم هنا تقريبًا ما نخطط له:

• الإصدار التالي هو Auk وهو رمز مكتمل مع إنهاء المولد وتحديث المستندات. التغييرات الفاصلة في مصادقة الريش v1.0.0
• الإصدار التالي هو Buzzard والذي سيتضمن التغييرات الأساسية التالية (والتي أشير إليها في بعض الأحيان باسم v3 - وربما لا ينبغي):
  
  
  
  • استقلالية الإطار (https://github.com/feathersjs/feathers/milestone/9) (ومع ذلك هيكل موحد للعميل )
  
  
  • خطاف في النواة (https://github.com/feathersjs/feathers/issues/408)
  
  
  • تصفية الأحداث القائمة على القناة (https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856)
  
  

ماذا يجب أن تكون العملية لتحديث التعريفات بمجرد وصول هذه الميزات؟

تكون تعريفات التنضيد مثل .h ​​(الرأس) في C ++. إذا كان لديك رأس لا يستجيب للوحدة النمطية الخاصة بك ، فقد تحدث مشكلات في وقت التشغيل ، مثل الوثائق التي لا تتوافق مع إصدار الكود المستخدم.

لذلك ، أعتقد أنه يجب تضمين التعريفات في كل معلم يتطلب تغييرًا في واجهة برمجة التطبيقات ، على سبيل المثال: نقل الطريقة إلى مستودع آخر أو إضافة معلمة جديدة إلى طريقة ، ...

سأقوم بتغيير تعريف مصادقة الريش ، وإزالة الخطافات إلى مشاريع محددة لتتماشى مع الإصدار 1.
السؤال الآن هو: هل يجب تضمين التعريفات في هذا الإصدار الحالي من FeathersJS؟

تضمين التغريدة يمكنني إصدار إصدار بسيط لجميع العلاقات العامة الخاصة بك ويمكننا التكرار من هناك. الشيء الوحيد الذي ما زلت أتساءل عنه هو # 508 لكنني سأعلق على ذلك.

أواجه مشكلتين مع الكتابة أعلاه.

لا يريد socketio العمل.

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

والباقي يتطلب معالجًا على الرغم من أن مخرجات feathers-cli الخاصة بك بدون حجج.

.configure (rest ()) // خطأ هنا يعلن بقية الوظيفة (المعالج: الوظيفة): الوظيفة ؛
.configure (socketio ())

عقدة الخامس
الإصدار 6.6.0

npm -v
3.10.5

tsc -v
2.1.6

سيكون من المثير للاهتمام أيضًا توضيح كيفية استخدام "feathers ()" كوحدة نمطية لأن هذه هي نقطة الدخول.
يمكنني تحويل جميع الخدمات / البرامج الوسيطة الأخرى التي تم إنشاؤها ولكن يجب أن تكون هناك طريقة أفضل لتغليف الريش () في المُنشئ () {}. (أنا جديد على الريش ، ربما أرتكب خطأً أيضًا ...)

هل يمكننا إخراج التعريفات كإصدار تصحيح؟ سيكون هذا المستوى من التغيير مناسبًا تمامًا لإصدار التصحيح ؛ لا تغييرات جذرية ولا وظائف جديدة. حتى الكتابة الجزئية أو غير الصحيحة أفضل من عدم الكتابة.

بمجرد أن يكون لدينا إصدار ، يكون لدينا نقطة بداية عمل يمكننا استخدامها لتحسين الكتابة.

إذا استمر هذا في الركود وسيتعين عليك السير في طريق DefinitelyTyped لتعريفاتي. لا أريد القيام بذلك ويسعدني المساعدة في التعريفات في المستودعات.

كان لدي سؤال عن AbraaoAlves في # 508 لكن لم أحصل على رد حتى الآن. إذا قمنا بإصدار الإصدارات ، فنحن بحاجة إلى شخص متاح للتعامل بسرعة مع أي مشكلات قد تظهر (خاصة وأن أسوأ الحالات قد تؤدي إلى كسر التطبيقات الحالية التي تستخدم TypeScript). هل يمكننا التنسيق على Slack للحصول على وقت جيد لعمل الإصدار والتحقق منه (يمكننا البدء بـ mini.pre)؟

صدر في إصدارات ثانوية لكل وحدة عن طريق

• 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

بادئ ذي بدء ، شكراً لكل من شارك في هذا النقاش وخاصة أولئك الذين ساهموا. لقد أصدرنا إصدارات ثانوية مع تعريفات TypeScript للعديد من مستودعات Feathers ولكنها تسببت في عدد من المشكلات - والإصدارات غير المجدولة للوحدات النمطية المستقرة إلى حد ما ، مما يجعل المستخدمين يقومون بالتحديث حتى لا يستخدمون TypeScript على الإطلاق - مع عدم وجود وسيلة للجوهر فريق (حيث لا يستخدم أحد TypeScript) لإصلاحها بشكل موثوق.

إن استنتاجي الرئيسي من مناقشة Feathers + TypeScript بأكملها هو أنه يبدو أنه من الصعب جدًا إنشاء والحفاظ على كتابات لمشروع JavaScript موجود (بالنسبة لي لم يتحدث بشكل جيد عن ادعاءات TypeScript للتشغيل البيني). نظرًا لأن الفريق الأساسي لا يستخدم TypeScript ، فإن خيارنا الوحيد للمضي قدمًا عند إصدار تغييرات API المعطلة هو إزالة أي تعريفات TypeScript قديمة.

سيكون من الرائع الحصول على تعريفات TypeScript محدثة لوحدات Feathers في مستودع DefinitelyTyped وسنبذل قصارى جهدنا للمساعدة في تحقيق ذلك ولكن مع الوقت المحدود المتاح لدينا ، لا يمكننا إضافة النفقات العامة لـ دعم وصيانة شيء لا نستخدمه شخصيًا في مستودعاتنا.

بالنسبة لي التي لم تتحدث بشكل جيد عن ادعاءات TypeScript الخاصة بإمكانية التشغيل التفاعلي

الريش قابل للاستخدام تمامًا بدون أنواع محددة ، إنه مجرد JS عادي ثم بدون التحسس والأنواع. نظام المكوِّن الإضافي للريش على وجه الخصوص مع استخدامه المكثف للخلطات يجعل إنشاء الكتابة أمرًا صعبًا ، لأن هذه طريقة غير مطبوعة للغاية للقيام بالأشياء. أنا مستخدم عادي للطباعة المطبوعة (وأحبها) ، لكنني عدت إلى ES6 لأشياء الريش من جانب الخادم في الوقت الحالي.
يبدو أن الحفاظ على الأنواع بشكل منفصل هو الطريقة الأنسب هنا مع عدم استخدام أي شخص في الفريق الأساسي للطباعة.

سيكون الريش هو الإطار الجانبي المفضل للخادم لـ Angular إذا تم لعبه بشكل جيد مع TypeScript. مجرد قول' :-). سأنتقل الآن.

@ j2L4e أعتقد أن هذا سيكون أسهل للإصدار التالي بمجرد أن تصبح معظم الأشياء التي يتم مزجها الآن بواسطة المكونات الإضافية جزءًا من النواة. لست متأكدًا مما إذا كان سيحل المشكلة العامة المتمثلة في الحصول على مساعدة موثوقة في هذا بالرغم من ذلك.

rjsteinert ما هو موجود في الوقت الحالي يجب أن يعمل في الغالب ولكن نعم ، كما هو الحال مع أي مشروع مفتوح المصدر لديك الفرصة إما للمحاولة والمساعدة أو المضي قدمًا.

لديك فرصة للمحاولة والمساعدة أو المضي قدمًا.

أنا واحد من هؤلاء الأشخاص الجدد على Angular ، مبرمج JS منذ فترة طويلة ، وأدرك مدى تأثير TS على الحياة ، وأدرك أنه إذا لم نتعامل معها على جانب الخادم ، فإن الفريق سيلعن ذلك ويتخيل إعادة الكتابة كل يوم على مدى العامين المقبلين. قد نذهب بعد كل شيء مع الريش بسبب نقص الخيارات وفي هذه الحالة نساعد بالتأكيد في الحفاظ على الطباعة محدثة. فقط نقول أنه عندما نمر ونرى "خيارنا الوحيد للمضي قدمًا عند إصدار تغييرات API المعطلة هو إزالة أي تعريفات TypeScript قديمة" ، فإننا ننظر في مكان آخر. لا تأخذ الأمر على أنه أمر بسيط ، فأنا أفهم الحاجة إلى دعم المشاريع الحالية ، فأنت لست محظوظًا بما يكفي (قد أكون محكومًا علي بالفشل) لتكون في وضعي حيث نقوم بإعادة الكتابة.

rjsteinert ما الذي يقدمه TypeScript والذي يجعله ذا قيمة كبيرة بالنسبة لك؟ (سؤال صادق) بعد أن اكتملت مجموعتي الحالية من أعمال الريش ، فضولي قد أثار اهتمامي بما يكفي لإلقاء نظرة على TypeScript بنفسي. أعلم أنه يساعد في الإكمال التلقائي / CodeSense ، لكن واجهة Feathers API صغيرة جدًا ولا يمكنني تخيل أنها مفيدة. يرجى العفو عن جهلي. ؛)

autocomplete/CodeSense منتج ثانوي لطيف لكنني عادة في Vim لذا لا أحصل على الأشياء الجيدة. التحول الكبير الذي أراه حتى الآن هو توحيد المعايير حول كيفية توضيح كيفية استخدام بعض الوظائف أو الكائنات المساهمة. من خلال البحث في المكتبات في NPM ، أجد الكثير من المكتبات تستخدم حلولها المحلية والمبتكرة لتوضيح ما لا تخبرك به اللغة المكتوبة ديناميكيًا وقابليتها للاستخدام. يحفظ TS الكثير من لوحة الغلاية من النوع الذي يتحقق من الأشياء بنفسك عندما تكتب رمزًا ويسهل فهم كيفية استخدام رمز شخص آخر بسرعة. في هذه الأيام ، أميل إلى الاعتقاد بأنني سئمت من كتابة لوحة المرجل JS هذا هو أسلوبي الخاص ولا أريد حقًا قراءة README لشخص ما في كل مرة أستخدم فيها مكتبة خارجية.

أتفق مع rjsteinert ، لقد عملت مع JavaScript لأكثر من 15 عامًا وأنا معجب كبير بتذكر جميع واجهات برمجة التطبيقات. حتى أنني اعتدت على كتابة التعليمات البرمجية باستخدام برنامج Notepad بدون أي لون. كنت أعمل في فريق في Microsoft حيث تمت كتابة الموقع بالكامل باستخدام JavaScript فقط. يمكنني إخبارك بمجرد وصول موقعك إلى أكثر من 50 مبرمجًا ، يصبح كل شيء في حالة من الفوضى. ليس عليك فقط اتباع المزيد من الاتفاقيات ، ولكن موقعك يتعطل فقط في وقت التشغيل.

إذا كنت تكتب على منشور GitHub هذا وتستخدم FeatherJS ، فأنت على الأرجح مطور جافا سكريبت متعطش. إذا كنت أحد مطوري FeatherJS ، فلن ترى أي فائدة من استخدام TypeScript لنفسك. لا تحتاج إلى أي أدوات خاصة أو تعليمات TypeScript. أنت يونيكورن جافا سكريبت.
كنت شديدًا ضد TypeScript (خاصة أننا اضطررنا لاستخدامه مع الإصدار Alpha 1.1) ، ولكن على مر السنين ، تعلمت أن أقدره ولا يمكنني العيش بدونه. الزملاء الذين ستعمل معهم لن يكونوا على دراية كما أنت في JavaScript. سوف يأتون من جميع الخلفيات المختلفة ، وسوف يشتمون كيف أن JavaScript قطعة من الهراء.

نمت لغة TypeScript كثيرًا من تعليقات المجتمع منذ ذلك الحين.
لا يمكنك إنشاء موقع ويب ضخم بدون أدوات وفريق كبير. كما يقول rjsteinert ، سيبدأ الفريق في استخدام TypeScript من أجل العميل ، ثم بعد فترة ، سيكونون غير سعداء للغاية باستخدام جانب الخادم. سيتم بذل الجهود لتغيير البنية التحتية لتلائم متطلبات شركتهم ، ثم سيتم التخلص من featherjs جانبًا.

ألق نظرة على اللغات الأكثر شيوعًا المستخدمة على الويب: PHP و NodeJS و Ruby و C # و Java ... بعضها مكتوب وبعضها ليس كذلك. لقد عملت مع كل هذه اللغات ويمكنني أن أخبرك أنه بعد كل هذه السنوات ، لا أريد العودة إلى لغة "اكتشاف الخطأ في وقت التشغيل فقط". كل منهم له سحر وإيجابيات وسلبيات. في فريق كبير ، أقترح دائمًا استخدام شيء أقوى قليلاً ومكتوبًا.

أحدث مثال كتبته لشخص يستخدم PHP SDK. إذا كانت لديك طريقة تقبل "عددًا كبيرًا" مكونًا من 100 رقم ، فأنت في الواقع تعامل كسلسلة. سيفتح المطور المبتدئ خطأ يسأل لماذا عند استدعاء setValue(123456789123...) لا يعمل ، يبدو أنه يتعطل منخفضًا جدًا في NodeJS أو بطريقة substr . الآن ، سيتحقق المطور المتوسط ​​من وثائقك ويجد أنه كان ينبغي أن يكون سلسلة. تخيل مع الكتابة ، فإنك تفرض إدخال سلسلة أثناء الكتابة أو الترجمة. ثم لا يحتاج المطور لقراءة الوثائق المحددة ولا يفتح الخلل.

لقد بحثت قليلاً عن إطار العمل الذي يجب استخدامه لمشروع Angular2 + NodeJS الجديد الخاص بي ، وبدا أن FeatherJS هو ما احتاجه تمامًا. ومع ذلك ، إذا ظهر مشروع خادم آخر اليوم وقال "أنا أدعم TypeScript رسميًا خارج الصندوق" ، فسأنتقل فورًا.

شكرا لمساهمة الجميع في هذه القضية. كانت هناك بعض المناقشات الجيدة للغاية ولكني أشعر أنها بدأت في التحول نحو مزايا الكتابة المطبوعة وهذا ليس حقًا ما يدور حوله هذا الموضوع. ناقش الفريق الأساسي ولن ندعم تعريفات الطباشير لأنها ليست ضرورية للعمل مع الريش وسوف تقلل من المعدل الذي يمكننا من خلاله تطوير جوهر الريش. لدينا بالفعل العديد من الأشياء لتحديثها عند إصدار إصدار. نحن نحاول تقليل التبعيات من أجل الحصول على الإصدارات في وقت أقرب ، في حين أن إضافة تعريفات Typescript ستضيف المزيد من العمل. نظرًا لأنه لا يوجد أحد في فريق Feathers الأساسي يستخدم كتابًا عاديًا ، فإننا:

1. ليس لديهم المعرفة الكافية للحفاظ على التعاريف بشكل صحيح
2. لا يمكن قضاء الوقت في العمل على التعريفات عندما "تتطلب" نسبة صغيرة من قاعدة مستخدمينا. لدينا الكثير من العناصر الأخرى للعمل عليها والتي تؤثر على المزيد من الأشخاص.

بالنسبة لأولئك الذين يرغبون في إنشاء / الاحتفاظ بتعريفات رسمية ، يسعدنا ربطها في قسم النظام البيئي في المستندات الجديدة ، ولكن نظرًا لعدم استخدامها بأنفسنا ، فإن تعريفات TS ليست مطلوبة عند استخدام Feathers وهي تفضيل شخصي أكثر لن نحافظ عليها. سنقوم بسحبها من المستودعات الحالية و https://github.com/feathersjs/feathers-typescript. إذاjsgoupil،rjsteinert،AbraaoAlves أو أي شخص آخر المهتمة ترغب في الحفاظ على الريبو سنكون سعداء لمنح حق الوصول و / أو نقل الريبو. نعتقد أن هذا سيجعل من السهل تحديث التعريفات ويسهل إرسالها إلى DefinitelyTyped (من المسلم به أنني لا أعرف الكثير عن هذه العملية).

سنترك هذه المشكلة مفتوحة للمناقشة ولكننا سنغلق الخيط إذا استمر في مسار مناقشة مزايا Typescript بدلاً من ما يجب القيام به لتنفيذ التعريفات خارج الريبو الأساسي. 😄

إذا كنت لا ترغب في تضمين هذا ، هل يمكنك من فضلك تضمين أدلة المصدر في الإصدارات المنشورة على npm وتعيين jsnext:main أو module في package.json إلى الإدخال

نظرًا لأن TypeScript يدعم تعريفات وحدة wildcard الآن ، فسيكون حلًا سهلًا لإزالة جميع الكتابة من وحدات الريش الفرعية وإدراجها في feathers :

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

والتي ستعلن عن الريش وجميع أنواع الريش - مهما كانت الوحدات النمطية كنوع any ، مما يجعلها على الأقل تعمل مع TS خارج الصندوق. لا تحصل على تحسس محسن ولكنه يعمل فقط دون كسر الأشياء في المشاريع الحالية ويزيل المشكلة من ظهور الناس.

أود أيضا أن تفعل:

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

"لتجاوز" محارف الكتابة غير الصحيحة أو غير المكتملة في هذه الأثناء ، بدلاً من فتح الكثير من العلاقات العامة الصغيرة وإنشاء الكثير من إصدارات التصحيح التي لا تقوم في الواقع بتصحيح أي شيء للمستخدمين الذين لا يستخدمون TS.

مرحبا،
أريد فقط توضيح شك واحد بخصوص دعم الطباعة.
وفقًا لتعريف النوع الحالي للخدمة ، فإن جميع طرق الخدمة هي طرق مطلوبة.

ولكن وفقًا للوثائق ، فإن طرق الخدمة اختيارية.
نرى

لذا ، يجب أن يكون تعريف الخدمة على النحو التالي ، أليس كذلك؟

  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 نعم هذا صحيح

أنا متمسك بحل "تجاوز محارف الريبو" في الوقت الحالي ، وربما في يوم من الأيام (عندما تتقاطع الأصابع) أنشر على ريش مطبوع أو بالتأكيد من النوع ، بمجرد أن أنتهي من مشروعي.

يضمن ذلك أنني سأرسل بعض التعريفات التي تم اختبارها في المعركة في مشروع إنتاج واحد على الأقل.

شكرا يا كو!

في الثلاثاء 9 مايو 2017 الساعة 7:42 صباحًا ، ريتشارد مايكل كو <
[email protected]> كتب:

@ harish2704 https://github.com/harish2704 نعم هذا صحيح

أنا متمسك بحل "تجاوز محارف الريبو" في الوقت الحالي ، و
ربما في يوم من الأيام (الكالينجيون الأصابع) تنشر على ريش مطبوعة أو
بالتأكيد من النوع ، بمجرد أن أنتهي من مشروعي.

هذا يضمن أنني سأرسل بعض التعريفات المختبرة في المعركة في
مشروع إنتاج واحد على الأقل.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
.

تضمين التغريدة
قد يكون من المبكر بعض الشيء تسجيل الوصول - ولكن كيف تعاملت مع المحارف؟ هل تحتاج يد المساعدة على الإطلاق؟ :) أتطلع إلى استخدام الريش في مشروع جديد ، لكن نقص دعم TypeScript يمثل نقطة شائكة إلى حد ما.

نقص دعم TypeScript

لست متأكدا ما تعنيه بالضبط. انها تعمل تماما. إنه بعيد عن الكمال ، لكنه يعمل.

jonlambert أتفق مع @ j2L4e. الموجود منها ليس مثاليًا ، لكني أفعل الحيلة التي ذكرتها هنا لأي شيء لا يتحقق من الكتابة.

IMHO ، حزم مثل feathers-rest التي يجب استخدامها فقط في سطرين تقريبًا لا تستحق الكتابة على الإطلاق :-)

لا أستطيع حتى تذكر ما قمت بتغييره ، لكنني أعتقد أنه لا توجد مشاكل في استخدام الخطافات والخدمات.

@ j2L4e كنت feathers لا يدعم TypeScript. أنت على حق ، من الممكن استخدامها مع الحل البديل الذي ذكرته أعلاه ، لكنه بالتأكيد ليس "مدعومًا" كما نرى في هذه المشكلة!

تعد TypeScript جزءًا لا يتجزأ من سير العمل لدينا في ضمان إمكانية صيانة تطبيقاتنا باستمرار ، لذلك اعتقدت أن الأمر يستحق التحقق لمعرفة ما إذا كانت تعريفات myknbani متاحة أم لا. لا تقلق رغم ذلك! 🙂

إنه يعمل بدون هذا الحل أيضًا. هناك كتابات متوفرة في المستودعات الرسمية التي لا تحتاج إلى الكثير من العبث. بلا إهانة ، لكن يبدو لي أنك لم تحاول حتى إذا نجحت.

نظرًا لأنه لا يوجد أحد في فريق Feathers الأساسي يستخدم كتابًا عاديًا ، فإننا:

1. ليس لديهم المعرفة الكافية للحفاظ على التعاريف بشكل صحيح
2. لا يمكن قضاء الوقت في العمل على التعريفات عندما "تتطلب" نسبة صغيرة من قاعدة مستخدمينا. لدينا الكثير من العناصر الأخرى للعمل عليها والتي تؤثر على المزيد من الأشخاص.

بصفتي قادمًا جديدًا إلى إطار العمل ، كنت أعتقد أن وجود هذه المشكلة ، بالإضافة إلى التعليقات أعلاه كانت كافية لافتراض عدم وجود دعم TS. آسف إذا كان هذا هو الاستنتاج الخاطئ ، فسأكون متأكدًا من تجربته.

أيضًا ، قد "يعمل" ، ولكن بدون أي شكل من أشكال الضمان لضمان بقاء تعريفات النوع محدثة مع واجهة برمجة التطبيقات ، يبدو أن لديها القدرة على التسبب في مشاكل في المستقبل.

أنت على حق.

ومع ذلك ، كان هناك عدد غير قليل من التحسينات في الآونة الأخيرة ومن المقرر الانتهاء من عمليات الطباعة.

هذه أخبار رائعة 🙂 أستمتع حقًا بالعمل مع إطار العمل حتى الآن وأنا متحمس لاستخدامه مع TS 🎉

إنه يعمل بدون هذا الحل أيضًا. هناك كتابات متوفرة في المستودعات الرسمية التي لا تحتاج إلى الكثير من العبث. بلا إهانة ، لكن يبدو لي أنك لم تحاول حتى إذا نجحت.

@ j2L4e أنت على حق. أعتقد أن المحارف في حالة أفضل بكثير الآن. لقد حذفت جميع "الإلغاءات" والمشكلة الوحيدة المتبقية حتى الآن هي تأكيدات ! (Coz من strictNullChecks ) عند استخدام app.service(...) .

أود أن أقترح فصل الكتابة لتعريف الخدمة (حيث تكون جميع طرق الخدمة اختيارية) ومثيل الخدمة (حيث لا تكون جميع طرق الخدمة غير محددة). حاليًا ، كان علي أن أضيف بشكل مؤلم ! s في كل مكان على سبيل المثال await app.service('api/foos').create!([{

كان لدي هذا في الحل الخاص بي:

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>;
  }

كيف عن هذا:

  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;

يتيح لك ذلك كتابة أي خدمة بخلاف خدمة TS من خلال إنشاء نوع جديد ، على سبيل المثال لراديو الريش:

type MailerService = CreateService<Mail>;

أو خدمة (غير مجدية تمامًا) يمكنها فقط إنشاء وحذف:

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

هذا كله باستخدام وظائف المحدد لوضع الخدمات في الاعتبار (على سبيل المثال ، app.service (s => s.mailout)) سيعيد تلك الخدمة بنوعها المناسب. كما يظهر هنا:

فقط التحقق مرة أخرى ، كيف نحن؟ @ j2L4e آخر ^ يبدو أنيقًا حقًا! فقط أتساءل ما الذي يجب القيام به لمعرفة ما إذا كان بإمكاني تقديم أي مساعدة.

حسنًا ، الأخطاء التي أراها حتى الآن:

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] تحل الوحدة النمطية '"c: / Users / George / Source / Repos / ts4 / node_modules / feathers-errors / not-found"' إلى كيان غير وحدة نمطية ولا يمكن استيرادها باستخدام هذا التكوين.

[2]

الوسيطة من النوع "Function" غير قابلة للتخصيص إلى معلمة من النوع "PathParams".
النوع 'Function' غير قابل للتخصيص للنوع '(سلسلة | RegExp) []'.
الخاصية "push" مفقودة في النوع "Function".

[3]

الوسيطة من النوع "Function" غير قابلة للتخصيص إلى معلمة من النوع "PathParams".
النوع 'Function' غير قابل للتخصيص للنوع '(سلسلة | RegExp) []'.
(الاسم المستعار) notFound (): الوظيفة

هل هناك حلول حالية؟

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

بالنسبة للإصدار التالي ، قام @ j2L4e ببعض العمل الرائع في تلميع الكتابة. فيما يلي خطوات تجربته واختبار الإصدار التجريبي:

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

ستقوم lerna بربط جميع الحزم والأقسام نيابة عنك. انتقل الآن إلى. تحقق من index.ts.

للترجمة والتشغيل ، قم بتشغيل npm start from ./packages/tests

بدأت للتو الترحيل من Feathers 2 إلى 3 ، ملفات index.d.ts مفقودة الآن من حزم headfeathersjs . أي خطط لاستعادتها؟

كما ذكر أحد التعليقات أعلاه ، فقد تم نقلهم إلى https://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4e ليتم إرسالها إلى DefinitelyTyped. @ j2L4e مشغول جدًا في الوقت الحالي ، لذا فإن الأمر متروك لشخص آخر لالتقاط هذا. مما فهمت أنه في الغالب هو الحصول على اجتياز Linting وتقديمهم إلى DefinitelyTyped. سأساعد بسعادة كل من هو على استعداد لالتقاط هذا ولكن ليس لديه خطط لتحمله بنفسي.

نعم ، لقد كان عملاً أكثر بكثير مما كنت أتوقعه وكانت التعليقات من المجتمع صفرًا تقريبًا. سأحقق ذلك بمجرد أن أجد الوقت. ليس مبكرا جدا ، رغم ذلك.

إذا كان أي شخص يتناغم هنا ، فسيكون رائعًا حقًا. الأمر كله يتعلق بفحص DT الآن ، بغض النظر عن كل شيء يعمل بشكل جيد

نسخة سريعة ولصق من Slack:

يا رفاق ، أنا مشغول حقًا في الوقت الحالي ، لذا فإن الكتابة ليست سوى أولوية قصوى. إنهم يقومون بعملهم ولكن بالتأكيد نوع DefinitelyTyped صارم تمامًا من حيث قواعد الفحص. إذا كان بإمكانك المساعدة في جعل الكتابة تمر بعملية الطباعة الدقيقة ، فسيكون ذلك رائعًا

تحقق من DT fork الخاص بي هنا https://github.com/j2L4e/definitelytyped ، ستجد حزم feathersjs في types/feathersjs__packagename

clone، npm تثبيت وتشغيل linter على إحدى الحزم ، على سبيل المثال npm run lint @feathersjs/feathers (محرر)

@feathersjs/feathers يُفحص بالفعل بشكل صحيح ، لذا يمكنك استخدامه كمرجع. (معدل)

تنتظر تعريفات TypeScript المراجعة لتتم إضافتها إلى DefinitelyTyped على https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22805

التعريفات يمكن الوصول إليها الآن عبر NPM!

نعم ، قم بتثبيت @types/feathersjs__package للحزمة @feathersjs/package وقدم بعض الملاحظات من فضلك!

erikma شكرا لدعمكم!

@ j2L4e شكرا @featherjs/express ؟ لا يمكنني العثور على أي ذكر للراحة ، json ، notFound و url المشفرة في ملف تعريفات الكتابة المطبوعة.

أنت على حق ، هؤلاء مفقودون.

قم بإضافة ملف typings.d.ts الآن مع:

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;
    };
}

لا فكرة أين يجب أن يذهب urlencoded.

urlencoded و json إلى express في الإصدار الثانوي الأخير. هل لم يتم تحديث كتابات express بعد؟

هل هذا صريح أم feathersjs / صريح؟

تمت إعادة تصديره للتو من 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

لذا يجب أن تكون قادرًا على القيام بـ Import { urlencoded, json } from '@feathersjs/express' ؟ أو هل ستحصل عليه من original ؟

كل شيء يتم تصديره من require('express') يُعاد تصديره بواسطة @feathersjs/express : https://github.com/feathersjs/express/blob/master/lib/index.js#L82

أيضا ، هل تعرف كيف تتعامل مع channel.ts بتعريفات جيدة؟
أنا آسف لإلقاء كل المشاكل عليك في مثل هذا الوقت القصير.

استيراد @ أنواع / feathersjs__socket-commons

يستورد ؟ لم افهم

معذرةً ، يجب أن تقول "استيراد @ feathersjs / socket-commons". تحتاج إلى تثبيت أنواعها.

إذا قمت بتثبيت @types/feathersjs__feathers فإنني app.channel لا يعمل. إذا قمت بعد ذلك بإضافة @types/feathersjs__socket-commons app.on توقف عن العمل

سيتم إصلاحه عبر DefinitelyTyped / DefinitelyTyped # 23195

يرجى أخذ أي مشكلات أخرى هنا: https://github.com/feathersjs-ecosystem/feathers-typescript/issues

يعد تتبع المشكلات لتعريفات TS أمرًا مربكًا بعض الشيء. أنت توجه الأشخاص إلى الريش المطبوع على الورق ولكنك ذكرت _ "هذا الريبو عفا عليه الزمن الآن" _. إذا كنت لن تحافظ على التعريفات في مستودعات إعادة الشراء المعنية وبدلاً من ذلك تستخدم DT ، أعتقد أنه سيكون من المنطقي الاحتفاظ بالمشكلات في DT repo أيضًا ، نظرًا لأنه من المفترض أن يتم إنشاء العلاقات العامة ودمجها.

أعتقد أننا قررنا أن نجربها هنا. لقد تلقيت طلبات من خلال عدة قنوات ، وكان توجيه الناس للذهاب إلى هناك طريقة سريعة لمركزية ذلك. أنا شخصياً لا أهتم حقًا إلى أين يذهب طالما أنه مكان واحد

هل هناك أي سبب يمنعنا من استخدام feathers.services.dogs بدلاً من feathers.service('dogs') ؟

نعم. feathers.service('dogs') calls defaultService (الذي ينشئ خدمة على العميل) ويزيل الشرطات المائلة من أسماء الخدمة.

أصبحت تعريفات TypeScript الآن في DefinitelyTyped .

يرجى توجيه أي مشكلات وأسئلة إلى https://github.com/feathersjs-ecosystem/feathers-typescript/issues