هل تستخدم بعض أدوات التجميع الأخرى مثل browserify أو webpack على المخرجات التي تم إنشاؤها؟ أو هل تتوقع أن يعمل هذا مباشرة على العقدة؟

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

حسنًا ولإضافة سياق ، تم تصميم "paths" للاستخدام مع اللوادر التي تسمح بإعادة التعيين ، على عكس Node.js require() . يتمثل السلوك المقصود في السماح لـ TypeScript بحل معلومات النوع للعديد من معرفات الوحدة النمطية التي تستخدمها برامج التحميل المختلفة ، وليس لإعادة كتابة معرفات الوحدة النمطية. في الأساس لا تفعل ما كنت تعتقد أنها فعلت. كما أنه لا ينبغي في رأيي أن يكون لديه القدرة على عكس استراتيجيات دقة اللوادر.

mhegazy كنت أتوقع أن يعمل مباشرة مع العقدة. إنه لتطبيق خلفي. هل kitsonk صحيح في التصريح بأن هذا يعمل على النحو المنشود وأن الكتابة المطبوعة لن تعيد كتابة مسارات الوحدة؟

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

استجابة مماثلة https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

حسنا شكرا. قد يكون من المفيد توثيق ذلك بشكل أفضل لمنع المزيد من الخلط بين الناس. أستخدم الآن https://www.npmjs.com/package/module-alias لجعله يعمل مع العقدة.

تقديراً لموقف TS ، إليك حل بسيط لحالة الاستخدام بنسبة 90 ٪ لمن يستخدمون العقدة ، لكنهم يريدون الراحة في استخدام مكالمات baseUrl نسبة require() بدون أي ضجة.

يربط هذا الحل استدعاء العقدة require() ، ويحل الطلبات باستخدام اسم الدليل "main" لتقليد baseUrl . لذلك يفترض أن خيار المترجم baseUrl قد تم ضبطه أيضًا على نفس الدليل حيث يوجد المصدر "main.ts".

للاستخدام ، الصق هذا الجزء الصغير من التعليمات البرمجية في الجزء العلوي من "main.ts".

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)
  }
})()

إذا كنت ستستخدم الحزمة module-alias التي ذكرها mika-fischer ، فلاحظ أن المسارات التي تسجلها في الحزمة لا يجب أن تنتهي بـ / ، والمسارات مرتبطة بالمسار حيث package.json (قد يكون واضحًا ولكن من الجيد توضيحه) ،

لذلك إذا كان لديك هذا في ملف tsconfig الخاص بك:

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

يجب عليك تسجيل هذا في package.json الخاص بك:

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

حسنًا ولإضافة سياق ، تم تصميم "المسارات" للاستخدام مع برامج التحميل التي تسمح بإعادة التعيين ، على عكس Node.js يتطلب (). يتمثل السلوك المقصود في السماح لـ TypeScript بحل معلومات النوع للعديد من معرفات الوحدة النمطية التي تستخدمها برامج التحميل المختلفة ، وليس لإعادة كتابة معرفات الوحدة النمطية. في الأساس لا تفعل ما كنت تعتقد أنها فعلت. كما أنه لا ينبغي في رأيي أن يكون لديه القدرة على عكس استراتيجيات دقة اللوادر.

جئت إلى هنا بعد إضاعة بعض الوقت في محاولة إعداده في مشروع كبير.
إذا كان هذا السلوك لن يتغير ، فأقل ما يمكنك فعله هو تحديث الوثائق قبل إغلاق هذه المشكلة.
لا تذكر الوثائق الرسمية https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping٪ 20docs شيئًا عن الاضطرار إلى استخدام "أدوات تحميل تسمح بإعادة التعيين" على الإطلاق.

قم بتثبيت وتشغيل "tspath" في مجلد مشروعك ... https://www.npmjs.com/package/tspath

@ef-carbon/tspm

يمكنك أيضًا تجربة "momothepug / tsmodule-alias" لتحليل مسار الاسم المستعار:

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

فقط https://www.npmjs.com/package/module-alias عملت معي ...

لقد تمكنت أيضًا من الحصول على هذا العمل باستخدام اسم مستعار للوحدة النمطية ، مع الجانب السلبي الذي يجب أن أتتبعه في كل من tsconfig.json و package.json. هل وجد أي شخص حلا أبسط؟

الحل الذي أشار إليه mattyclarkson يعمل أيضًا ، لكن لم أتمكن من العثور على طريقة لاستخدامه جنبًا إلى جنب مع ts-node. أيه أفكار؟

ألق نظرة على https://github.com/momoThePug/tsmodule-alias

2018-05-31 15:04 بتوقيت جرينتش -05: 00 edufschmidt [email protected] :

لقد تمكنت أيضًا من الحصول على هذا العمل باستخدام اسم مستعار للوحدة النمطية ، مع الجانب السلبي
يجب أن أتتبع الأسماء المستعارة الخاصة بي داخل كل من tsconfig.json و
package.json. هل وجد أي شخص حلا أبسط؟

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

شكرًا DanyelMorales ، هذا مفيد حقًا.

على الرحب والسعة! :)

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

شكرًا DanyelMorales https://github.com/DanyelMorales ، هذا حقًا
سهل.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

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

كيف ينبغي للمرء أن يقوم بتعيين المسار النسبي للأشياء التي ليست وحدات نمطية ، أي ليست مستوردة؟

في برنامج نصي للعقد يقرأ دليلًا معينًا متعلقًا بالملف المصدر الذي اعتدت فعله:

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

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

كيف ينبغي للمرء أن يقوم بتعيين المسار النسبي للأشياء التي ليست وحدات نمطية ، أي ليست مستوردة؟

هذا هو حقًا "كيف يمكنني استخدام سؤال Node.js و TypeScript" ويتم طرحه بشكل أفضل في Gitter.im أو StackOverflow.

أنا أحب TypeScript لكن هذا جنون.

أنا لا أفهم. حتى مع علمي القليل عن مصدر أكواد TS ، لا ينبغي أن يكون هذا صعب التنفيذ. لقد بدأت للتو في استخدام مشروع مشترك مع العميل والخادم ... لماذا يقدم TS وظائف المسارات في المقام الأول ، ثم يجعلني أقفز عبر الأطواق لاستخدامها بالفعل؟ لماذا تفترض TS أنني أريد استخدام أداة تجميع / محمل مع كل مشروع أقوم به؟ أحاول استخدام TS لتبسيط مشاريعي ، وليس التعامل مع المزيد من مكتبات الأدوات للتعويض عن ميزة TS التي تم تنفيذها بنسبة 90٪.

أنا أتفق معك. أعتقد ، تم تطوير TS للواجهة الأمامية ، لأن حزمة الويب
يقوم بالفعل بتنفيذ مسارات ts alias بشكل جيد جدًا ، وكذلك مع Requirejs
نفس الشيء. لكن بالنسبة لمشاريع Nodejs ، الأمر صعب للغاية. :(

El jue.، 20 de sept. de 2018 02:50، Josh Pike [email protected]
escribió:

أنا لا أفهم. حتى مع علمي القليل عن مصدر أكواد TS ، هذا
لا ينبغي أن يكون صعب التنفيذ. لقد بدأت للتو في استخدام مشروع مشترك
مع العميل والخادم ... لماذا يقدم TS وظائف المسارات بتنسيق
في المقام الأول ، ثم يجعلني أقفز عبر الأطواق لاستخدامه بالفعل؟ لماذا
هل تفترض TS أنني أريد استخدام أداة تجميع / محمل مع كل مشروع
صنع؟ أحاول استخدام TS لتبسيط مشاريعي ، وليس القيام بالمزيد
مكتبات الأدوات للتعويض عن ميزة TS التي تم تنفيذها بنسبة 90٪.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

+1!

قد تساعدني حزمة الويب على حل خرائط المسار (أو أداة أخرى مثل babel-plugin-module-resolver ) ولكن ليس الإعلانات ( .d.ts ) .

لم يتم حل جميع المسارات في الإعلان.

ركض في هذه القضية أيضا. يبدو أنه من المنطقي أن تتضمن التعليمات البرمجية المنبعثة تعيينات المسار. لجأ إلى اسم مستعار . لكن +1 لـ Typescript لتوفير هذه الوظيفة اختياريًا.

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

+1

يمكنك تجميع واردات TypeScript المطلقة والقائمة على المسار إلى ملفات Javascript النسبية باستخدام ts-transformer- import و ttypescript

لقد قمت بإنشاء حل وقت الترجمة حيث يمكنك الاستمرار في استخدام tsc . https://github.com/joonhocho/tscpaths

Microsoft / TypeScript # 15479 (تعليق)

لقد صدمت للتو بهذه المشكلة عند محاولة الحصول على vue-cli لإخراج ملفات d.ts حيث يوجد الكثير من import {foo} from "@/some/folder/foo" وملفات d.ts الناتجة لا تحل الاسم المستعار.

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

وظيفة المترجمين هي إخراج ملفات javascript AND d.ts الصالحة لملفاتك المطبوعة ، وهي ببساطة لا تعمل في هذا السيناريو الصالح (باستخدام المسار المستعار 'في ملفات tsconfig).

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

لا يمكن للمتسولين أن يكونوا منتقيين ، ولكن استخدام Typescript يتجنب العديد من الجوانب المحبطة لـ Vanilla JS وأنا أحسب الواردات النسبية ('../../../../../utils/parser') لتكون واحدة منهم. سيكون من المدهش أن تنظّف المطبعية هذه!

codeitcody يبدو مثل ذلك. من الغباء أنه سينتج شيئًا لا يعمل ببساطة بدون حزمة تابعة لجهة خارجية ولكن هذا هو الواقع.

حسنًا ، أليست هذه مشكلة لطيفة تقع عليها.

يبدو أن وجود ميزة تجعل تطبيقك غير قابل للاستخدام بشكل أساسي دون القفز عبر الأطواق (أي تثبيت المزيد من التبعيات لحل المشكلة).

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

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

mhegazy هل يمكنك أنت أو أي شخص آخر إخبارنا إذا كان من المحتمل الآن بعد عامين أن يقوم فريق TypeScript بإلقاء نظرة على هذا مرة أخرى وإعادة النظر؟

قد تساعدني حزمة الويب على حل خرائط المسار (أو أداة أخرى مثل babel-plugin-module-resolver ) ولكن ليس الإعلانات ( .d.ts ) .

لم يتم حل جميع المسارات في الإعلان.

هل هناك طريقة لتحقيق ذلك؟ لدي مكتبة مكونات تفاعل مخصصة وقد تلقيت هذا الخطأ عند محاولة استخدام paths لاسم مستعار. أقوم بعمل الحزمتين مع التراكمية والأنواع بـ --emitDeclarationOnly

لا يمكنني استخدام اسم مستعار للوحدة النمطية لأنه يقول:

تحذير: لا يجب استخدام هذه الوحدة في وحدات npm الأخرى لأنها تعدل سلوك الطلب الافتراضي!

الرجاء المساعدة في التصويت على هذا المنشور على Reddit: https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
لا أعرف لماذا يحتاج هذا النقاش الضخم هنا. يجب أن يكون من السهل حل هذا الخطأ. خيار في tsconfig ويمكن للجميع تحديد ما إذا كان يريد السلوك الحالي (لأي سبب كان) أو نهج العمل.

واجهتنا نفس المشكلة في Dropbox وفتحنا هذا المحول https://github.com/dropbox/ts-transform-import-path-rewrite

لقد مررت بنفس التجربة عدة مرات الآن ، أتوقع أن يتم حل الاسم المستعار للمسار ولكني ما زلت أنسى أنه يجب علي تثبيت اسم مستعار للوحدة النمطية وتحديث package.json واستيراده في الملف الرئيسي. سيكون رائعًا إذا تم التعامل مع هذا في خطوة الترجمة من خلال تنميد سكريبت.

أوتش. هذه ضربة حقيقية لـ TypeScript. أين المعنى في هذا؟

ملاحظة لا يمكننا التعليق فقط +1

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

لول ، سأقوم فقط بتثبيت امتداد npm لشيء يمكن لفريق TypeScript إضافة دعم له. ربما يجب عليهم التوقف عن إضافة المزيد والمزيد من التحسينات وإضافة ميزات أساسية.

@ ميكا فيشر
كيف تستخدم https://www.npmjs.com/package/module-alias بحيث تتوقف eslint للتحذير من "المسار الذي لم يتم حله" @ root / bla / bla "(في ملفات JS)؟ وكيف يمكن تمكين الإكمال التلقائي لمثل هذه المسارات في WebStorm و VS Code؟

بالنسبة لي ، يعمل الإكمال التلقائي للواردات في VSCode افتراضيًا في مشاريع الكتابة المطبوعة.

bobmoff نعم ، يبدو أن كل شيء جيد لاستيراد ملفات TS من ملفات TS.
لكن الإكمال التلقائي والتنقل لـ "تتطلب ('@ root / bla / bla') من ملفات TS لا يعمل.

أرغب في ترجمة مشروع JS الخاص بي إلى TS ، واعتقدت أنه يمكنني إعادة تسمية ملفات js إلى ts واحدًا تلو الآخر.
أدرك الآن أنه صعب للغاية وغير مدعوم من قبل ts ولا IDEs ، ويجب علي إعادة تسمية جميع ملفاتي js إلى ts مرة واحدة.

لأنني إذا قمت بإعادة تسمية ملف JS واحد فقط إلى TS ، فإن جميع المسارات النسبية في دليل build تصبح معطلة (ربما يجب أن أستخدم "allowJs: true" ، لكن لدي مشروع واحد به 2 غيغابايت من ملفات JS ، إنه كذلك من الغريب أن نجمعهم في بناء dir٪)).
حسنًا ، أحاول حل هذا من خلال أسماء مستعارة للوحدة النمطية ، وتوقف التنقل والإكمال التلقائي في IDE الخاص بي عن العمل ويحذر eslint من 100500 "مسارات لم يتم حلها". أنا بالفعل أكره بعض الشيء TS ، يبدو أن الترحيل لمشاريع JS الكبيرة ليس بهذه السهولة كما يقول الناس للتسويق في TS. يبدو أن ترحيل مشاريع JS الخلفية إلى golang أكثر بساطة :)

لقد نجحت في استخدام tscpaths كحل بديل.

أنا أيضا. أنا حقا أوصي بـ tscpaths . يعمل كما يفترض.

الحل البسيط الخاص بي:

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

أو باستخدام عملية pm2

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

لقد عثرت للتو على هذا الأمر ، في بعض الأحيان يمكن أن يكون TypeScript بمثابة ألم حقيقي في المؤخرة.

أنا لا أفهم بجدية سبب استمرار هذا الموضوع ...
نعلم جميعًا عن "مسار الجحيم" ، ويمكنك (باستخدام الأسماء المستعارة) ذلك
حقا نظيفة
حتى هذه الفوضى ، الجميع في هذا الموضوع يعرف هذا!

يتم تفسير الأسماء المستعارة بواسطة برنامج التحويل البرمجي TypeScript ، وهو يقوم بالتجميع بدقة
كما ينبغى،
بالتأكيد لا ينبغي أن تتجول في جافا سكريبت الناتج ، إذا
تريد استخدامه
الأسماء المستعارة سيكون عليك حل هذا بأنفسكم!

.... أو بدء المواضيع في Apple و Google و Microsoft
مطالبتهم بتنفيذ وظائف في محركات JavaScript الخاصة بهم بحيث
يستطيعون
interpet الأسماء المستعارة الخاصة بك ؛-)

مترجم TypeScript يفعل بالضبط ما يجب أن يفعله!

إذا كنت تعمل في العالم الزاوي فالطريق ممهد ، إذا كنت ترغب في ذلك
تشغيل الخاص بك
رمز مباشرة في Node ، ستحتاج إلى أداة لحل المسارات ، ولدي
مصنوع
هذه الأداة مخصصة لك فقط ، فقد تم استخدامها في الإنتاج لأكثر من عام الآن ،
انها كونها
استخدمتها أكبر صحيفة هنا في السويد ، لقد صنعت هذا حتى تتمكن من ذلك
اذهب عارية
مع Node ، أنا لا أحاول بيع أي شيء هنا ، أنا لا أكسب المال
من هذا :)

ونعم ، هناك أدوات مثل "tsmodule-alias" وما شابه ذلك من الاختراقات ، يمكنك ذلك
في الواقع يجعله يعمل
إذا كنت حريصًا جدًا ، ولكن هناك فوضى ، فهناك حلول بديلة باستخدام
عقدة ts
سكربتات شل وما إلى ذلك ... yadda yadda

شعرت أخيرًا أن هذا يكفي ، لذا أغلقت نفسي بعيدًا وصنعت
TsPath
الأسماء المستعارة وقت الترجمة

> تثبيت npm -g tspatj

myproject> tsc

myproject> ملعقة شاي

أو

myproject> ملعقة شاي - f

مقطوعة الرأس (ثبت أنها مفيدة جدًا على خادم الإنشاء)

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

هتافات! :)

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

دن سون 13 jan. 2019 kl 22:20 skrev فابيو سبامبيناتو <
[email protected]>:

لقد عثرت للتو على هذا الأمر ، في بعض الأحيان يمكن أن يكون TypeScript بمثابة ألم حقيقي في ملف
الحمار.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

تضمين التغريدة

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

لا أوافق بشدة. ما لم تكن تمزح ، لا يمكنني القول حقًا.

يجب أن يقوم TypeScript بترجمة التعليمات البرمجية التي _works_ دون الحاجة إلى أداة جهة خارجية لإكمال المهمة التي تم تنفيذها جزئيًا فقط في المترجم الأصلي.

مترجم TypeScript يفعل بالضبط ما يجب أن يفعله!

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

وهو يولد رمزًا قابلاً للتنفيذ إذا لم تستخدم ميزات
غير مدعوم من قبل محركات جافا سكريبت ، من المفترض أن يكون ذلك منطقيًا جدًا
هناك ، على سبيل المثال: هل تلوم مترجم C ++ إذا كان تطبيقك
يستخدم مكتبات الارتباط الديناميكي وأن البرنامج لن يعمل على الجهاز
التي لم يتم تثبيت هذه؟

هذه ميزة يمكن استخدامها إذا كنت تدير المسارات ذات الصلة ،
تحمل المسؤولية عنها مثلما يفعل Angular مع WebPack أو كما أفعل مع
كل ما عندي من مشاريع TypeScript مع TSPath!

لا تستخدمها إذا كنت لا تفهم كيفية إنشاء بيئة عمل ،
لا أعتقد حقًا أن هذه مسؤولية Microsoft هنا ، هم
قدمت ميزة وإليك كيفية عملها ،
قد لا تعمل بالشكل الذي تريده أو تتوقع أن تعمل ولكن هذا لا ينجح
من الخطأ!

كما أنني أشعر بالفضول ، هل تركت هذا الأمر يعيقك بجدية
التطوير باستخدام TypeScript؟

دن مان 14 يناير. 2019 kl 21:34 skrev Robert Main [email protected] :

مترجم TypeScript يفعل بالضبط ما يجب أن يفعله!

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

هذه ميزة يمكن استخدامها إذا كنت تدير المسارات النسبية ، وتحمل المسؤولية عنها مثل Angular مع WebPack أو كما أفعل مع جميع مشاريع TypeScript الخاصة بي مع TSPath!

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

حقيقة أن TS يحتاج إلى حزمة خارجية فقط حتى يمكن تنفيذ الكود الناتج أمر مثير للسخرية.

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

لقد فهمت دائمًا أنه كان من المفترض أن تقوم TypeScript بالتجميع إلى JavaScript. إذا كنت تخبرني أن بعض الميزات لا تدعمها محركات جافا سكريبت ، فلماذا توجد هذه الميزات بالضبط؟

هل ستلقي باللوم على برنامج التحويل البرمجي C ++ إذا كانت مكتبات الارتباط الديناميكي للتطبيق الخاص بك وأن البرنامج لن يعمل على جهاز ما لم يتم تثبيت هذه المكتبات؟

لا ، لكنني سألقي باللوم عليه إذا سمح لي بالربط برمز C ++ آخر لم يكن موجودًا بالفعل بدون أي خطأ أو تحذير في المترجم.

أنت حقا لا تفهم هذا ، أليس كذلك؟ لم يتم كسر الكود ، إذا كان
كسر ذلك لأنك قمت بتكوين المترجم
لإنشاء رمز لا يدعمه "النظام الأساسي" لديك ، في هذه الحالة ،
اسماء مستعارة!

في حالتك ، لا تستخدم الأسماء المستعارة ، "أنت" لا تدعمها ، بجدية!

حتى لو كان هذا إصلاحًا من سطر واحد (بالطبع ليس هذا هو الحال) فهو كذلك
مسألة ما يجب على المترجم و
لا ينبغي أن تفعل! تمت إضافة هذه الميزة من أجل دعم LOADERS لا
بالعكس ، اقرأ
عند تعيين المسار في الوثائق الرسمية ، فأنت تستخدمه مرة أخرى
خاطئ - ظلم - يظلم!

مرة أخرى ، هذه الميزة خاصة بـ Loaders / Resolvers ، لقد أساءت فهم كيفية القيام بذلك
يعمل ، لذلك لا ، Microsoft
يجب ألا يغير المترجم بحيث يمكنك لصق الأسماء المستعارة بدون امتداد
البيئة التي تدعمها!

دن تيس 15 يناير. 2019 kl 04:41 skrev فابيو سبامبيناتو <
[email protected]>:

هذه ميزة يمكن استخدامها إذا كنت تدير المسارات ذات الصلة ،
تحمل المسؤولية عنها مثلما يفعل Angular مع WebPack أو كما أفعل مع
كل ما عندي من مشاريع TypeScript مع TSPath!

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

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

إنها موجودة منذ أن استخدمت اللوادر تخطيط المسار ، وهذا هو سبب دعمها!
وبما أنك تصر (مثلي) على استخدامها بدون لودر ، فما هو ملف
مشكلة مع
باستخدام أداة بحيث يمكنك الاستفادة من الميزة؟

دن تيس 15 يناير. 2019 kl 05:10 skrev Robert Main [email protected] :

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

لقد فهمت دائمًا أنه كان من المفترض أن تقوم TypeScript بالتجميع إلى
جافا سكريبت. إذا كنت تخبرني أن بعض الميزات لا يدعمها
محركات جافا سكريبت فلماذا بالضبط هناك؟

هل تلوم مترجم C ++ إذا كان الارتباط الديناميكي للتطبيق الخاص بك
المكتبات وأن البرنامج لن يعمل على جهاز لا يحتوي على هذه
المثبتة؟

لا ، لكنني سألقي باللوم عليه إذا سمح لي بالربط برمز C ++ آخر لم يفعل ذلك
موجودة بالفعل مع عدم وجود خطأ أو تحذير في المترجم.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

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

من فضلك أشرني إلى هذا القسم من الوثائق.

تيس 15 يناير. 2019 ك. 05:31 skrev Robert Main [email protected] :

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

تمت إضافة هذه الميزة من أجل دعم LOADERS لا
بالعكس ، اقرأ
عند تعيين المسار في الوثائق الرسمية ، فأنت تستخدمه مرة أخرى
خاطئ - ظلم - يظلم!

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

duffman ألا ترى أن الناس هنا يريدون هذه الميزة فقط ؟؟؟ أنت تخبر الجميع أنه من الغباء أن يفهم كيف يجب استخدام هذه "الميزة". حسنًا - يمكنك النظر إلى هذا بهذه الطريقة ولكن من يدري - ربما يكون العكس ...

بالمناسبة رأيي هو التالي:

نظرًا لأن الأسماء المستعارة مضمنة في المترجم ، فإن تجميع المشروع معهم أمر جيد. قد يجعل المستخدمين يعتقدون أنه يعمل بالطريقة التي تقترحها (وهذه المشكلة دليل جيد إلى حد كبير على أنني على حق). حتى أنه يبدو غير منطقي - لماذا يعمل شيء ما في المحرر "الرسمي" (vscode - خاصة عند استخدام ميزة "الاستيراد التلقائي" ، يستخدم vscode مسارًا مستعارًا) ، لماذا يعمل برنامج النسخ أيضًا بشكل جيد ، عندما لا يعمل الكود الناتج؟ إن قول "محرك js لا يدعمه" يجعلني أرغب في طرح المزيد من الأسئلة - ألم يكن المقصود من TS كشيء للتخفيف من بعض "مشكلات" JS؟

أتوقع أحد حلين لهذا:
1) تجاوز الواردات بأسماء مستعارة بشكل صحيح
2) عرض تحذير

أعتقد أن القول "إنه سلوك صحيح" خطأ. ليست كذلك. TS ليست لغة تجميع ، ولا حتى C / C ++.

يجب على فريق التطوير إضافة دعم لتحليل الاسم المستعار. أقترح إضافة أ
مفتاح لتحليل المترجم في tsconfig.

سيكون من الجميل مايكروسوفت !!!!!!

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

:( الكل هنا حزين وغاضب (وجائع) بسبب تباطؤ
التناسق. المطبوع رائع ، أنا أحبه ...

نحن نحبها!

مع أطيب التحيات مطور بلا مأوى ...

El mar.، 15 de ene. de 2019 08:02، Mike S. [email protected]
escribió:

بالمناسبة رأيي هو التالي:

تم تضمين الأسماء المستعارة في المترجم ، فالتجميع على ما يرام. قد تجعل المستخدمين
أعتقد أن الأمر يجب أن يعمل كما يعتقدون (وهذه المشكلة إلى حد كبير
دليل جيد على أنه صحيح). يبدو غير منطقي - لماذا يعمل شيء ما فيه
محرر "رسمي" (vscode - خاصة عند استخدام ميزة "الاستيراد التلقائي" ،
يستخدم vscode مسارًا مستعارًا) ، لماذا يعمل copiler أيضًا بشكل جيد ، عند الكود الناتج
لا يعمل؟ إن قول "محرك js لا يدعمه" يجعلني أرغب في السؤال
أكثر من ذلك - ألم يكن المقصود من TS كشيء للتخفيف من بعض "مشاكل" JS؟

أتوقع أحد حلين لهذا:

1. تجاوز عمليات الاستيراد بأسماء مستعارة بشكل صحيح
2. عرض تحذير

أعتقد أن القول "إنه سلوك صحيح" خطأ. ليست كذلك. TS ليس كذلك
لغة التجميع ، ولا حتى C / C ++.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

. TS ليست لغة تجميع ، ولا حتى C / C ++.

لا أفهم حقًا ما تحاول الإشارة إليه من خلال إثبات أن TS ليست C ++ ، ومعظمنا يدرك جيدًا ذلك على ما أعتقد!

لقد أثبتنا أيضًا أن الاسم المستعار / تعيين المسار يُستخدم في الإنتاج في جميع أنحاء العالم ، لذلك بطبيعة الحال ، يجب أن يدعم VS Code ذلك ، ولكن لا يزال من غير المنطقي أن يقوم MS بصياغة المترجم ليلائم الإعداد الخاص بك!

ما أجد صعوبة في فهمه هو سبب استمرارك في ذلك ، يعمل المترجم كما يفترض أن يعمل ، مرة أخرى ، اقرأ المستندات التي توضح بوضوح الغرض من الميزة!

أعني أنه يمكنك إعداد بيئة تطوير TS عاملة باستخدام أسماء مستعارة للمسار في غضون دقيقتين ، إذا كنت لا تريد استخدام WebPack ، فيمكنك استخدام TSPath لحل جميع المسارات في جميع ملفات js في ثانية واحدة ، وإضافتها إلى الحزمة .json كنصوص تشغيل وليس عليك حتى التفكير في الأمر ، فالمشكلة غير موجودة ، ويبقى المترجم بالطريقة التي كان من المفترض أن يعمل بها ويمكنك أن تستمر في العمل وأنت سعيد !؟

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

استدعاء أكبر خمسة مساهمين في TypeScript : ahejlsberg @ andy - msDanielRosenwassersandersnsheetalkamat

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

لم تترك لي حالة هذه المشكلة أي خيار آخر سوى خفض رتبة TS لكتابة واجب المدقق فقط.
لدى Babel الآن دعم لائق لبناء جملة TS ، بالإضافة إلى babel-plugin-module-resolver يقوم بمهمة إرسال كود العمل لحالة الاستخدام هذه على ما يرام.
الجانب السلبي الوحيد هو تكرار أجزاء التكوين من tsconfig.json لأن Babel لا يهتم بتكوينات TS. لكنه سعر مقبول للعمل في المسارات المطلقة في مشاريع العقد وكمكافأة أحصل على النظام البيئي بأكمله بأشياء رائعة مثل وحدات ماكرو بابل.

هذا هو الحد الأدنى من الإعداد الذي عملت به كبديل لمترجم 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
• package.json :
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• في tsconfig.json :

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

• .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"   
  ]
}

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

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

دن مان 28 يناير. 2019 kl 15:59 skrev 叶伟伟[email protected] :

أريد فقط استخدام الكتابة المطبوعة مع المسار المطلق ، ولكن يبدو أنه لا بد لي من ذلك
config webpack أو babel أو شيء من هذا القبيل ، من الصعب جدًا تحقيقه !!!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

ترك هذا هنا لأن حالة استخدام موثقة فعلية للسلوك الحالي paths لم يتم ذكرها في هذا الموضوع: حزم @types/ لا تحتوي على ميزات backport فيما يتعلق بـ semver. ومع ذلك ، فهي تتضمن أنواعًا محدثة لواجهات برمجة التطبيقات القديمة التي يمكنني استخدامها. على سبيل المثال ، أستخدم history@2 عندما يكون history@3 هو الأحدث.

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

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

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

للمرة الثانية خلال ورشة عمل TS على مستوى الشركة ، اضطررت إلى شرح هذا السلوك غير العادل والمحرج ...

عنجد!

أي نوع من مترجم اللغة ، خاصةً الذي يكون عرض مبيعاته الأساسي أكثر دقة لجافا سكريبت ، ينتج تعليمات برمجية معطلة كـ "ميزة"؟!؟!

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

انظر فقط إلى عدد المرات التي تمت فيها الإشارة إلى هذا ... يا له من مضيعة للوقت والاهتمام لكثير من الناس.

أتفهم إحباطك ، لكن الكثير من الناس يشعرون بأن السلوك صحيح ، لا يعني أنه الشيء الصحيح الذي يجب فعله.

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

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

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

نظرًا لأن أداة معينة لا تحل مشكلة لديك ، فهذا لا يعني دائمًا أن خطأ الأدوات هو ذلك. ربما ليس لديك كل الأدوات التي تحتاجها لحل مشكلتك.

kitsonk كل ما قلته بعيدًا عن الواقع.

تكمن المشكلة في أن TS سيعمل بطريقة ما أثناء التطوير / الاختبار ، وأخرى بعد اكتمال التجميع.

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

لا ، وهذه هي المشكلة.

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

لا أعتقد أن أي مناقشة حديثة كانت بناءة مؤخرًا ، ولا أتوقع أي تغييرات مستقبلية هنا ، لذلك سأغلق هذه المشكلة.