Typescript: منع "مسار الاستيراد لا يمكن أن ينتهي بامتداد '.ts'"؟

افترض أن لديك ملفين:
a.ts : import * as b from "./b.ts";
b.ts : export const b: number = 0;

عندما نقوم بتجميع a.ts ، فإننا لا نغير محددات الاستيراد . لذا فإن الناتج a.js سيحتوي على نفس محدد الاستيراد "./b.ts" ، على الرغم من احتمال ترجمته إلى require("./b.ts") .
ثم عندما تحاول تشغيل a.js ستفشل ، لأنه لن يكون هناك b.ts للاستيراد منه ، فقط b.js . (أو بدون --outDir حيث يكون b.js بجوار b.ts ، سيتم حل عملية الاستيراد إلى b.ts ، ثم تفشل عملية التحليل عند : number . )

بدلاً من ذلك ، يجب حذف امتداد الملف من الواردات ، أو استخدام الامتداد .js .

لا ， انا استعمل deno exec الملف。 بدون تجميع。

@ hooper- hc
أعتقد أنه يمكننا تعيين tsconfig كحل مؤقت مثل هذا:

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

أنا أستخدم دينو أيضًا. لقد اكتشفت أن التعليق على // @ts-ignore كل سطر من استيراد يعمل.

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

هل هناك على أي حال لإغلاق هذا المطلب على الصعيد العالمي في ts-config؟

لقد جربت أيضًا حل zhmushan ولم يحل المشكلة :(

reggi إزالة ./
آمل أن نتمكن في المستقبل من استخدام تكوين مشابه لـ module:deno لتبسيط العملية.

هل سيكون فريق TypeScript مفتوحًا لإضافة "module": "deno" إلى tsconfig؟ بهذه الطريقة يمكننا دعم استخدام الامتداد .ts محليًا ، دون الحاجة إلى اللجوء إلى شيء مثل kitsonk / deno_ls_plugin كحل بديل. يمكن أن تحاول أيضًا فرضها أيضًا ، لذلك إذا حاولت وفعلت

import module from 'module';

سيظهر خطأ مثل Cannot have an extensionless import with module:deno (الواردات الوحيدة المسموح بها هي عناوين URL كاملة ، والواردات النسبية تبدأ بـ ./ أو ../ ). يمكن لتكوين من هذا القبيل أيضًا أن يدعم البحث الأصلي في المجلد $DENO_DIR/deps عن الأنواع ، نظرًا لأننا نحتاج حاليًا إلى استخدام إعداد مسار لحل ذلك. علاوة على ذلك ، يمكن أن تعمل عمليات الاستيراد التلقائية بشكل صحيح أيضًا ، نظرًا لأنها تقوم دائمًا حاليًا بالاستيراد بدون امتداد (مما يعني أنه يتعين عليك تحريره يدويًا على أي حال).

يبدو هذا كنسخة مكررة من # 11901 والتي تم إغلاقها وإسكات صوتها للأسف. هذا مهم بالنسبة لـ Deno كما قيل من قبل وآمل أن يجعل TypeScript هذا التحقق من الامتداد قابلاً للتكوين أو حتى يزيله تمامًا.

في معظم النظام البيئي لأدوات جافا سكريبت ، يمكنك القيام بأشياء مثل import picture from 'image.png' ، والتي من الواضح أنها ليست Javascript. الافتراض هو أن بعض الأدوات ستعرف كيفية تحويل الملف المرجعي إلى جافا سكريبت بحيث يعمل هذا بشكل صحيح. تعمل جميع أنواع الأصول والصيغ البديلة ، مثل JSX ، بهذه الطريقة.

من ناحية أخرى ، تتوقع شركة Typescript أن تستخدم امتدادًا فارغًا أو الامتداد .js ، والذي يختلف عن كيفية عمل بقية النظام البيئي. يتسبب هذا في احتكاك أدوات مثل Deno أو rollup.js التي تتوقع امتداد الملف الأصلي.

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

إضافة تصويتي هنا لدعم دينو. يؤدي السلوك الحالي إلى حل TypeScript لجميع الأنواع المستوردة بهذه الطريقة إلى any ، مما يجعل تطوير البرامج لـ Deno أمرًا صعبًا إلى حد ما.

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

إذا أراد tsc أن يعمل مثل بقية العالم

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

@ jpike88 لا اوافق. لم أدرك وجود هذه المشكلة. كانت هناك بعض المشكلات الأخرى شبه ذات الصلة التي كنا نتتبعها. هذه المسألة لا تذكر أي شيء عن نية الفريق. لا يزال يتم تصنيفها على أنها سؤال ويمكن القول إنها نسخة مكررة من # 16577 أو # 18442.

على الرغم من أن

ما زلت أعتقد (وأعتقد أنني قلت هذا في مشكلة من قبل) أنه قد يكون هناك وقت لـ "moduleResolution": "literal" والذي من شأنه أن يفعل ما يقوله على العلبة ، ويسمح لـ TypeScript بافتراض أن أي مضيف وقت التشغيل سيحدده خارج / تغيير محددات الوحدة.

حسنا، ولكن:

https://github.com/microsoft/TypeScript/issues/18442
لقد علقت بالفعل على ذلك منذ عامين ، وما زال بعد كل هذا الوقت اقتراحًا للمرحلة الأولى.

https://github.com/microsoft/TypeScript/issues/16577
أيضًا أكثر من عامين ، ولا يزال في مرحلة "المناقشة". أيضًا بالمعدل الجاري ، لن يحدث في أي وقت قريب.

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

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

تحدث مشكلة مماثلة إذا كنت تريد استيراد ملف .mjs
على سبيل المثال ، import { forEach } from https://unpkg.com/[email protected]/index.mjs

هذا مغلق ، لكن لم يتم إصلاحه.

إذا كان أي شخص هنا يبحث فقط عن طريقة تمكنه من تشغيل TypeScript في سياق كل من Node.js و Deno ، فاعلم أن Webpack + ts-loader سيتيح لك الاحتفاظ بـ ".ts" في وارداتك.

لدي هذه المشكلة عندما أقوم باستيراد ملف من دينو؟ أي حل لإصلاح هذا باستثناء إضافة // @ts-ignore ؟

هل هذا ثابت؟ لا يعد الاستيراد بدون ملحق جزءًا من JS على أي حال ، ويجب ألا يؤدي استخدام الامتدادات إلى ظهور خطأ.

وأنا أتفق مع التعليقات الواردة أعلاه. إنه لأمر سيء للغاية أن المشكلة لم يتم حلها بعد.
لقد وجدت امتدادًا لـ vscode من المفترض أن يساعد ، لكن للأسف لا يعمل بشكل صحيح.
على أي حال ، سأترك الروابط هنا:
1) https://github.com/justjavac/vscode-deno
2) https://github.com/axetroy/vscode-deno

متابعة @ TicTak21 :
الروابط التي ذكرها تم إهمالها الآن لصالح المكون الإضافي الرسمي deno:
https://github.com/denoland/vscode_deno
تعمل هذه الإضافة على إصلاح عمليات الاستيراد .ts و URL (لذلك لا مزيد من الأخطاء) بشكل صحيح ،

danbulant ما زلت أرى الخطأ باستخدام المكون الإضافي vscode_deno.

أستخدم أيضًا Deno ولكني أعتقد أن المشكلة هنا ليست حول .ts مقابل لا .ts . يتعلق الأمر أكثر بالقدرة على السماح لـ tsc بتجاهل أي رقم خطأ. على سبيل المثال ، شيء مثل tsc --ignore TS2691 .

يعد ملحق Deno لـ vs code أمرًا رائعًا ، لكنه لا يحل المشكلة ، بل يقوم فقط بقمع الخطأ في المحرر. لدي مكتبة أرغب في إنشائها لـ deno والمتصفح ، لكن لا يمكنني ذلك لأن tsc سوف يرمي.

تضمين التغريدة
أوافق 100٪. هذا هو السبب الرئيسي الذي يجعلني لا أعتبر دينو بديلاً لـ node.js على الخادم. تتوفر بالفعل أطر عمل ويب جيدة لـ Deno ، ولا يقف سوى TYPESCRIPT في طريق هذا الحلم الجميل

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

حالة الاستخدام الخاصة بي هي أنني أعمل في بيئة بها كود مطبوع مشترك بين العميل والخادم باستخدام ارتباطات رمزية. تمت كتابة الخادم مع وضع deno في الاعتبار ، ويتم كتابة العميل بنص عادي ومطور 3. الحزم الذي أستخدمه ، الطرد ، يمكنه التعامل مع الملفات المطبوعة باستيراد ملفات .ts (على الأقل مع parcel-bundler ^1.12.4 ). هذا يترك التحسس ليتم إصلاحه.

deno_ls_plugin يعمل بشكل رائع بالنسبة لي ، لأنه حرفياً يقوم فقط بتصحيح دقة الوحدة النمطية .ts . في احسن الاحوال! هذا يعني أنه يمكنني استيراد الكود المشترك ، وكتابة الكود المشترك مع deno في المقدمة وقبل كل شيء في العقل ، وإصلاح التحسس لجانب العميل المطبوع على الحروف.

بالنسبة للمبتدئين ، قمت بتشغيل الأمر yarn add typescript deno_ls_plugin --dev لتثبيته. بعد أن رأيت أن intellisense لم يتم إصلاحها ، لاحظت بعض النصوص الصغيرة في الجزء السفلي من الملف التمهيدي deno_ls_plugin ، لاستخدام إصدار مساحة العمل من الكتابة المطبوعة .

بالنسبة لأي شخص آخر مرتبك قليلاً بشأن كيفية القيام بذلك ، فإليك ما فعلته:
أولاً ، قمت بتثبيت deno_ls_plugin و typescript كاعتمادات تطوير ، وقمت بتحديث tsconfig.json لتضمين deno_ls_plugin كمكوِّن إضافي

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

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

بعد ذلك ، اخترت تحديد الإصدار المطبوع

واختاروا إصدار مساحة العمل.

في حالتي الخاصة ، قمت أيضًا بتعيين printcript.tsdk في .vscode/settings.json لكنني لا أعرف ما إذا كنت بحاجة إلى ذلك.

إذا كان أي شخص آخر يحاول أيضًا مشاركة كود deno مع كود الكتابة المطبوعة ، فقد استخدمت ارتباطات رمزية للربط بالرمز الأساسي في كل من الخادم والعميل ، وكان الرمز داخل مرجع الارتباط الرمزي هو ملف deps.ts خارجه من أجل التبعيات (نظرًا لأن import_map هو نوع من أجهزة الصراف الآلي) بحيث يمكن للنسخة المطبوعة استيراد حزمة npm ويمكن لإصدار deno استيراد عناوين URL.

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

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

هذه المشكلة تحتاج إلى إعادة فتح.

مطورو دينو لا يحصلون على الاحترام الذي يستحقونه هنا. لقد صنعوا وقت تشغيل مذهلًا استنادًا إلى TypeScript ، لكن مطوري TypeScript لن يضيفوا علامة للسماح له بالعمل بشكل صحيح. كيف يمكن لهذا الوضع المؤسف أن يستمر كل هذا الوقت ؟!

عدم القدرة على استخدام الامتداد .ts على الواردات يسبب ألمًا ومشاكل هائلة لمستخدمي Deno ، الرجاء مساعدتنا!

انها ليست في الواقع دينو محددة

بدون إمكانية تحديد الامتداد بشكل صريح ، ستواجه العديد من مطوري JS مشكلة

على سبيل المثال في مشروعنا vue نحدد دائمًا الامتدادات ، وإلا فسنواجه مشكلة في موقف مثل

./component.vue
./component.ts

import component from './component';

لماذا هذا مغلق؟ بالتأكيد ليست دينو محددة خاصة مع ظهور mjs

هذا الموضوع ليس سؤالاً ، إنه طلب ميزة. من فضلك هل يمكن لشخص ما تصحيح الملصق وإعادة فتحه؟ لا تعد إضافة // @ts-ignore يدويًا إلى كل عملية استيراد حلاً مقبولاً.

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

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

اعتبروني مجنونًا ، لكن يبدو لي أنه كان هناك بعض تضامن الشركات هنا. أنفقت الشركة الكثير من الأموال على العقدة (npm). ولا تريد بعض المبتدئين أن يسلبوا أرباحهم بأيديها .. لذلك لا أعتقد أنه يمكنك توقع الكثير من الود تجاه deno من vscode أو الكتابة المطبوعة

لحسن الحظ ، يمكنك استخدام مكون إضافي يقوم بالفعل بأكثر مما تطلبه وسيتحسن فقط.
https://marketplace.visualstudio.com/items؟itemName=denoland.vscode-deno

لكن المشكلة لا تكمن في دينو فحسب ، بل تكمن أيضًا في js العادية
https://github.com/microsoft/TypeScript/issues/27481#issuecomment -664401169

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

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

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

صدقني أنه لا توجد بعض العصابات المخفية لـ Microsoft / Node.js لقمع Deno. فريق TypeScript الأساسي وعضو في مجتمع Node.js وفريق Deno الأساسي يتحدثون بانتظام مع بعضهم البعض ويتعاونون.

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

هذا ليس عائقًا لدينو.

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

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

هذه في الحقيقة ليست مشكلة مع TypeScript / tsc . يتجه Node.js في طريق الوحدات النمطية الواضحة على أي حال ، وكيف سيتعاملون مع ذلك سيكون له تأثير على إمكانات دقة الوحدة التي تبلغ tsc أعتقد. أعتقد أن هناك محادثات مستمرة هناك ، حتى أتمكن من دعم ESM بشكل أفضل في Node.js.

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