Typescript: لا ينبغي أن يهتم tsc ويفشل مع ملفات ts خارج rootDir

للالتفاف ، أضفت "استبعاد" مرة أخرى إلى tsconfig.json

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

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

هنا هو tsconfig.json الخاص بي:

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": true,
        "noImplicitAny": true,
        "rootDir": "src",
        "outDir": "build"
    },
    "exclude": [
        ".idea",
        "build",
        "node_modules",
        "typings/globals",
        "typings/modules"
    ]
}

تبدو بنية المجلد الخاص بي كما يلي:

• مشروع
  
  
  
  • يبني
  
  
  • node_modules (ارتباط رمزي بـ ../node_modules)
  
  
  • node_modules
  
  
  • src
  
  

أريد أن يتم تجميع ملفات .ts الخاصة بي في مجلد src وإخراجها بنفس بنية المجلد إلى مجلد الإنشاء. أفعل ذلك حتى أتمكن من ضبط جذر المستند الخاص بي على مجلد الإنشاء وإبقاء src خارج جذر المستند. أتلقى رسائل خطأ حول ملفات .ts في مجلد node_modules ، نفس رسائل الخطأ مثل OP. ملاحظة أعلاه ، لدي node_modules مستبعدة. لماذا تشكو TS من هؤلاء؟

HillTravis يبدو أن مشكلتك هي نفسها https://github.com/Microsoft/TypeScript/issues/9552.

mhegazy لست متأكدًا من أنه نفس الشيء. نعم ، يشتمل بنيتي على ارتباط رمزي ، ولكن يجب تجاهل أي مكان يوجد به هذا الارتباط الرمزي.

في # 9552 ، لا يوجد مجلد src ، مما يعني أن مجلد node_modules موجود في المسار الذي يتم بناؤه. في السيناريو الخاص بي ، فإن الدليل الجذر الذي يجب أن يبحث فيه tsc هو src ، والذي لا يحتوي على node_modules. لذلك لا ينبغي أن ينظر إلى هذا المجلد على الإطلاق. علاوة على ذلك ، لدي مجلد node_modules مستبعد صراحة عبر tsconfig.json الخاص بي. لذلك يجب تجاهلها بشكل مضاعف. لدي أيضًا المجلد build مستبعد ، ويجب أن يغطي هذا الرابط الرمزي لـ node_modules بداخله.

أيضًا ، في # 9552 ، لم يكن هناك أي ذكر لرسائل الخطأ أو التجميع الفاشل.

يجب أن أذكر أيضًا أنني أستخدم TypeScript 1.8.10.

على وجه التحديد ، تقرأ رسائل الخطأ:

خطأ TS6059: الملف '/ المستخدمون/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.module.ts' ليس ضمن 'rootDir' / Users / thill / Projects / nrc / العميل / src '. من المتوقع أن يحتوي 'rootDir' على كافة ملفات المصدر.

خطأ TS6059: الملف '/ المستخدمون/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.ts' ليس ضمن 'rootDir' / Users / thill / Projects / nrc / العميل / src '. من المتوقع أن يحتوي 'rootDir' على كافة ملفات المصدر.

خطأ TS6059: الملف '/ المستخدمون/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/timepicker-event-interface.ts' ليس ضمن 'rootDir' / Users / thill / Projects / nrc / العميل / src '. من المتوقع أن يحتوي 'rootDir' على كافة ملفات المصدر.

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

كاختبار ، حاولت إزالة الرابط الرمزي. في الواقع ، لقد حذفت المجلد build بالكامل. ثم قمت بتشغيل tsc مرة أخرى ، وما زلت أرى الخطأ.

أثناء المزيد من الاختبارات ، حاولت التعليق على الاستيراد داخل الكود واستخدامات وحدة العقدة المعينة (ng2-datetime) واختفى الخطأ. لذلك لا أرى الخطأ إلا عندما أحاول استيراد وحدة العقدة هذه ، بغض النظر عن الارتباط الرمزي.

إذا نظرت إلى مصدر تلك الحزمة على GitHub ، فسترى أن ملف package.json به المعلمة "main" مضبوطة على "ng2-datetime.js" ، على الرغم من أن المؤلف نشر أيضًا ملف .ts بنفس اسم. يبدو أن هذا هو سبب المشكلة. إذا قمت بإنشاء ملفات .d.ts وحذف ملفات .ts ، تختفي المشكلة. تم تجميعه بدون مشاكل حتى بعد إضافة الارتباط الرمزي مرة أخرى.

لذلك مع كل الاحترام ، لا أرى كيف يمكن أن ترتبط هذه المشكلة بالرابط الرمزي على وجه التحديد. يبدو أنه يتسبب بشكل عام في حدوث مشكلات عندما يقوم المؤلف بتضمين ملفات .ts في الحزمة.

هل تعرف ما إذا كان هناك أي حل بديل لهذا؟ قال OP أعلاه إن العمل حوله عن طريق إضافة "استبعاد" مرة أخرى إلى tsconfig.json. لقد تم بالفعل استبعاد الدليل ، لكنه لا يزال يحاول تجميعه.

هل تعرف ما إذا كان هناك أي حل بديل لهذا؟ قال OP أعلاه إن العمل حوله عن طريق إضافة "استبعاد" مرة أخرى إلى tsconfig.json. لقد تم بالفعل استبعاد الدليل ، لكنه لا يزال يحاول تجميعه.

قد يكون هذا متعلقًا بآخر ، لكن لا يمكنني العثور عليه الآن. عند تحديد نوع ما ، حاول دائمًا tsc البحث عنه من node_modules ، بينما لا يوجد (متعلق بـ typings ).

"لا ينبغي أن تهتم tsc وتفشل مع ملفات ts خارج rootDir" أوافق.

لا أستطيع
تقول رسالة الخطأ "من المتوقع أن يحتوي 'rootDir' على جميع ملفات المصدر" ، لذا لا ينبغي توقع أو افتراض أي شيء خارج هذا الدليل كملف مصدر ، فيما يتعلق بـ TS!

إذا كان هذا هو "العمل على النحو المنشود" ، فما هو بالضبط القصد أو الدافع من هذا السلوك؟ هل هناك حالة يرغب فيها TS في تجميع ملفات المصدر الموجودة خارج rootDir؟

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

مع النسخة المطبوعة 1.8.10

كان لدي مجلد node_modules في homedir ~/node_modules . أدى تشغيل tsc من مشروعي dir ~/projects/myProject/ إلى تقديم شكوى من الملفات التالية

../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/config.d.ts(29,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(36,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(68,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(75,111): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/request.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/services/glacier.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.

محير للغاية - على الرغم من عدم التأكد من سبب وجود مجلد وحدات العقدة في دير منزلي لتبدأ به.

iwllyu يمكنك التحقق من مشروعك على [email protected] وتقديم مشكلة جديدة إذا كنت لا تزال تواجه مشكلة.

لا تزال تواجه مشكلة 2.1.4 على الرغم من أنها تشكو من مجموعة مختلفة من الملفات

Using tsc v1.8.10
../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(27,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(34,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(66,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(73,111): error TS1110: Type expected.

Using tsc v2.1.4
../../node_modules/aws-sdk/lib/config.d.ts(38,37): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/request.d.ts(164,16): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/s3/managed_upload.d.ts(15,16): error TS2304: Cannot find name 'Promise'.

سأقوم بإنشاء مشروع لعزل حالة الاختبار

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

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

كان هذا أيضا.
يعد الكتابة المطبوعة مقيدًا جدًا لفريقنا - التفكير في التدفق الآن.

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

ما هو الخيار الأفضل؟ النسخ واللصق هناك وهناك والتعديل إذا قمت بتغيير الأنواع؟

إن إنشاء مسار جذر واحد لمشروعين ليس خيارًا ، نظرًا لأن السبب وراء توفر معلومات عن jsx.json للخلفية عن jsx وتجميعها في Commonjs عندما يمكنني استخدام es2015

هل يعمل baseUrl أجلك؟

unional لن يغير baseUrl فكسر كل واردات node_modules - تتطلب عدم الكتابة

import * as request from "superagent";

لكن

import * as request from "node_modules/superagent/..something";

؟

بليه ، هذا حقا يعمل على النحو المنشود؟ لقد واجهت هذا للتو ، لقد أخبرت مطبعيًا أن مصدري كان كله في مجلد معين (عبر rootDir ) ثم انتقل إلى _تجاهل تمامًا ما قلته _ لأنني كان لدي ملف واحد به .ts ملحق

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

لأي شخص قادم بعدي ، فإن ما يلي سيفعل ما تريده _ في الواقع _:

{
    "compilerOptions": {
        "outDir": "./output",
        "rootDir": "./source",
    },
    "include": [
        "source"
    ]
}

أخبرت مطبعيًا أن مصدري كان كله في مجلد معين (عبر rootDir)

ليس هذا ما يعنيه rootDir ! يعني rootDir "استخدم هذا المجلد كأساس نسبي لحساب المسارات في outDir ". ما هي الملفات التي تشكل جزءًا من التجميع الخاص بك هو سؤال منفصل يتم الإجابة عليه بواسطة files و / أو include / exclude

حتى لو قبلت ذلك ، لا يزال السلوك الحالي في خطأ IMO. إذا كان لدي أي ملفات TS خارج الدليل المحدد ، فلن يكون rootDir هو الأساس لحساب المسارات في outDir ، مما يعني أن التكوين الذي حددته سيتم تجاهله تمامًا.

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

مثال على رسالة خطأ قد تكون أكثر وضوحًا (مع فشل شديد):

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

ملحوظة: جزء كبير من السبب في أن السلوك الحالي لـ rootDir يشعر بأنه خاطئ للغاية هو بالتحديد لأنه ليس من المنطقي أن يكون لديك ملفات خارج rootDir. عندما يسأل المرء نفسه (أو المترجم) ماذا يعني تجميع الملفات خارج rootDir فإن الإجابة الوحيدة هي "لا معنى لها". لذلك يصل المرء إلى الاستنتاج الطبيعي بأن rootDir يحدد sourceDir أيضًا.

الشر في التسمية. هذا يعني حقًا relativePathBaseDir أو شيء من هذا القبيل.

لقد لاحظت أيضًا أن include يعني عادةً "انظر هنا أيضًا" ولكن في هذه الحالة يعني "انظر هنا فقط".
سيكون من المعقول أن يكون لي اسم آخر وأن يكون إلزاميًا.

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

ملحوظة: جزء كبير من السبب في أن السلوك الحالي لـ rootDir يشعر بأنه خاطئ للغاية هو بالتحديد لأنه ليس من المنطقي أن يكون لديك ملفات خارج rootDir. عندما يسأل المرء نفسه (أو المترجم) ماذا يعني تجميع الملفات خارج rootDir فإن الإجابة الوحيدة هي "لا معنى لها".

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

+100 على هذا كونه خطأ (مقرف في الواقع). ضع في اعتبارك بنية الدليل التالية:

- src/
  - module.ts
- test/
  - module.test.ts
- out/
  - module.js

أود أن يقوم tsc بتجميع src ، لأنني أجري الاختبارات باستخدام ts-node . سيؤدي وجود rootDir: 'src' إلى حدوث خطأ في التجميع حاليًا. إذا قمت بتمييز الاختبارات والأشياء الأخرى التي تنوي تنفيذها فقط باستخدام ts-node (أو حتى الترجمة بشكل منفصل ربما؟) على أنها "مستبعدة" ، فحينئذٍ تبدأ الأشياء السيئة في الحدوث (على سبيل المثال ، يصبح تمييز vscode معطلاً في الاختبارات )

في الواقع ، لا توجد مجموعة من rootDir و excluded وجميع الخيارات الأخرى تفي بجميع المتطلبات (استبعد الاختبارات من التجميع مع الاستمرار في تشغيلها والعمل معها).

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

كان إعداد src / test / out سيناريو رئيسيًا تم تناوله من خلال مراجع المشروع

لقد وجدت هذه المشكلة لأنني كنت أبحث على Google عن سبب محاولة الكتابة المطبوعة تجميع ملف webpack.config.js بعد أن قمت بتعيين rootDir .

أخبرت مطبعيًا أن مصدري كان كله في مجلد معين (عبر rootDir)

ليس هذا ما يعنيه rootDir! rootDir يعني "استخدام هذا المجلد كأساس نسبي لحساب المسارات في outDir". ما هي الملفات التي تشكل جزءًا من التجميع الخاص بك هو سؤال منفصل يتم الإجابة عليه بواسطة الملفات و / أو تضمين / استبعاد

هذا هو الجواب! المستندات الخاصة بـ rootDir تقول

يحدد الدليل الجذر لملفات الإدخال

الذي اعتبرته يعني "إدخال ملفات _source_". أوصي بأن يحل تعليق RyanCavanaugh محل التفسير الحالي لهذا الخيار.

الربط هنا - https://github.com/Microsoft/TypeScript/issues/11299 هو نسخة مكررة من هذه المشكلة. (الحل: استخدم التضمين / الاستبعاد لتحديد الملفات المراد تجميعها ، ولا يحدد rootDir الملفات المراد تجميعها.)

mhegazy هل يمكنك إضافة تعليق على هذا الموضوع لهذا المعنى؟ يبدو أن هذا هو ما يشير إليه السائل (مرتبك بشأن سبب قيام TS بالنظر في أي ملفات خارج RootDir ، نفس سوء الفهم لما يعنيه rootDir).

أنا أيضًا أواجه هذه المشكلة ولم أتمكن من حلها.

يؤدي تجميع tsc إلى إخراج الشجرة من دليلي المضمن إلى المجلدات الرئيسية ، مما يتسبب في حدوث أخطاء في النوع المكرر.

لدي هيكل مجلد متداخل يشبه هذا:

└─src
└─package.json
└─node_modules
└─tsconfig.json
└─example
│ └─src
│ └─package.json
│ └─node_modules
│ └─tsconfig.json

الآن عندما أحاول تشغيل tsc من داخل دليل المثال ، أحصل على الخطأ التالي:

node_modules/@types/react/index.d.ts:2809:14 - error TS2300: Duplicate identifier 'LibraryManagedAttributes'.

2809         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                  ~~~~~~~~~~~~~~~~~~~~~~~~

  ../node_modules/@types/react/index.d.ts:2814:14
    2814         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                      ~~~~~~~~~~~~~~~~~~~~~~~~
    'LibraryManagedAttributes' was also declared here.

كما ترى من خلال الخطأ ، يقوم tsc بتوجيه الشجرة لأعلى وخارج مجلد المثال ، والبحث في مجلد node_modules للدليل الأصل! ما هو أسوأ من ذلك هو أنني حاولت بشكل صريح تجاهل دليل node_modules الأصلي مع تأثير ضئيل.

هنا هو tsconfig من المثال الدليل:

{
  "compilerOptions": {
    "target": "es5",
    "experimentalDecorators": true,
    "module": "commonjs",
    "sourceMap": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "jsx": "react"
  }
,
  "typeRoots": [
    "./node_modules/@types"
  ],
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules",
    "../node_modules"
  ]
}

كيف يمكنني حل هذه المشكلة؟ لا يبدو أن أيًا مما سبق ينجح بالنسبة لي

lexwebb كان لي نفس المشكلة، الاختيار في حياتك yarn.lock الملفات التي @types/react لديها نفس الإصدارات.
راجع https://stackoverflow.com/questions/52399839/typescript-duplicate-identifier-librarymanagedattributes.

لقد وصلت إلى هنا لأن مجلد الأصول الخاص بي يحتوي على ملف فيديو "MPEG Transport Stream" بامتداد .ts لذلك تسبب في تعطل tsc حتى لو لم يكن المجلد في مسار rootDir بي 😄

لقد أصلحته عن طريق إضافة مجلد الأصول في مسارات exclude لكنه كان سلوكًا مزعجًا 🤔

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

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

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

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

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

kpturner هذا يبدو معقولًا للغاية ، ولكن - مشروع اختبار مجردة بدون استيراد عبر المجلدات سينتج السلوك الذي يشتكي منه الجميع.

حقا؟ التي لم أرها من قبل :)

يتم دائمًا استبعاد المجلدات المستبعدة في جميع مشاريعي باستثناء الظروف التي أشرت إليها.

هل توجد أمثلة عظام عارية على هذا الخيط؟ من الصعب معرفة ذلك من هاتفي.

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

على سبيل المثال ، سيؤدي تجميع شيء كهذا إلى حدوث خطأ.

-src / src.ts <- no imports -test / test.ts -out -tsconfig.json {"rootDir": "src", "outDir": "out"}

ولكن إذا كان tsconfig.json يبدو هكذا ، أتوقع أن تقوم الكتابة المطبوعة بتجميع كل شيء في الدليل src وكل شيء في الدليل test . إذا كنت تريد فقط أن transpile الاشياء الوحيد في src والإخراج إلى out دليل فبالتالي tsconfig.json يجب أن يكون

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    }
}

ثم سيؤدي إلى ظهور خطأ TS6059 لأن لديك بعض الملفات خارج rootDir . لذلك عليك بعد ذلك استبعاد هؤلاء:

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    },
    "exclude": [
        "test"
    ]
}

والذي ، عند تحويله ، سينشئ مجلدًا يسمى out بمجلد فرعي src يحتوي على src.js . تم تجاهل المجلد test تمامًا. هذا ما أتوقع حدوثه - أليس كذلك؟

بالتأكيد ، يجب أن يتضمن المثال الخاص بي tsconfig rootDir و outDir تحت compilerOptions كما تظهر في المثال الأول. أنت محق أيضًا في أنه عند استبعاد test و test ويتم استبعاد ملفاتها. في الأصل ، ظننت أنك تقول إن الجاني (أو الجاني) في الخطأ TS6059 هو ملف في rootDir يستورد شيئًا من خارج rootDir الرغم من أنني أعتقد أنني أخطأت في قراءتك. بغض النظر ، أنا أتفق مع الآخرين هنا في اندهاشنا من أنه يجب استبعاد الدلائل خارج rootDir بشكل صريح كما وصفت.

لا ، كنت (سابقًا) أقول إن الشجرة المرجعية يمكن أن تؤدي إلى تحويل الأشياء في قائمتك المستبعدة - مختلفة قليلاً.

يعد خطأ TS6059 محيرًا بعض الشيء في البداية - لكني أرى أنه يحاول المساعدة في منعني من ارتكاب الأخطاء. إذا واجهت مشكلة في تحديد rootDir ثم طبع الذباب المطبوع خارج هذا rootDir ، فإن TS يقول بشكل فعال "oi - لقد قمت بإنشاء نسخة مطبوعة لا يمكنني الوصول إليها - هل هذا صحيح؟"

إما أن أجيب "لا ، ليس من الصواب أنني أفسدت" وأنقل الملفات إلى rootDir
أو
أقول "نعم ، هذا صحيح ، وأنا آسف لأنني لم أعلمك بذلك" - ثم أضفته إلى قائمة الملفات المستبعدة.

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

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

لا يمكن أن يكون هذا معقدًا ، أليس كذلك؟

بغض النظر عن الخيارات في أي مجموعة أستخدمها ، يبدو أن tsc غير قادر على التعامل مع monorepo باستخدام paths للإشارة إلى الحزم المحلية في نفس monorepo. لقد حاولت --build ، --project ، references ، paths ، extends ، rootDir ، rootDirs ، include ، exclude ، baseUrl ، outDir في كل أنواع التركيبات ذات القيم المختلفة وفي النهاية يشكو من أن الملفات ليست ضمن rootDir أو أنه يفسد من خلال إصدار بنية دليل خاطئة داخل outDir .

لن أصف ما لدي على أنه monorepo ولكن لدي ثلاثة مشاريع مختلفة في نفس الريبو - ويمكنني تحويل كل منها بشكل مستقل دون مشكلة أو تدخل من الآخرين. كل مشروع له tsconfig الخاص به

بعد بعض الوقت من المحاولة والعبث ، تمكنت من الحصول على references بالاشتراك مع paths ولا يختنق بعد الآن عند استخدام rootDir .

يتم استخدام rootDir لبناء بنية مجلد الإخراج. يجب أن تكون جميع الملفات تحت rootDir حتى يعرف المحول البرمجي مكان كتابة الإخراج.

ماذا عن الملفات التي لا تتطلب أي إخراج؟ وجود ملف json خارج الجذر:

const errors = require("../../../../errors.json");

لأنني لا أستطيع تجميع إصدار ES6:

import * as errors from "../../../../errors.json";

ومع ذلك ، مع الإصدار الأول ، أفقد نوع الأمان.

mhegazy تم إغلاق هذا الإصدار منذ 3 سنوات. ومع ذلك ، يبدو أنه لا يزال مصدر ارتباك بعد 3 سنوات.

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

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

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

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

كما ذكرت في https://github.com/microsoft/TypeScript/issues/9858#issuecomment -370653478 ، أعتقد أن حل هذه المشكلة هو ببساطة رسائل خطأ أفضل. مرة أخرى عندما واجهت المشكلة ، ووجدت في النهاية مشكلة GitHub هذه ، كان إحباطي الأكبر ناتجًا عن مقدار الوقت الذي أهدرته في محاولة اكتشاف المشكلة ، ثم التفكير في أنها كانت خطأ في المترجم ، ثم إنشاء حالة repro ، ثم العثور على خطأ مكرر يقول "يعمل على النحو المنشود". إن الفشل السريع برسالة خطأ واضحة كان سيوفر لي كل ذلك.

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

RyanCavanaugh شكرا

إذا ذهبت إلى هذه الصفحة: https://www.typescriptlang.org/docs/handbook/compiler-options.html. قرأت التعريف التالي:

يحدد الدليل الجذر لملفات الإدخال. استخدم فقط للتحكم في بنية دليل الإخراج باستخدام --outDir.

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

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

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

إن المعنى الضمني لملف خارج rootDir هو أن TS سينتج ملفًا خارج outDir ، والذي أعتقد أنه سلوك سيء بديهيًا.

يمكن أن تكون رسالة الخطأ أفضل - أحب اقتراحًا أو علاقات عامة لذلك.

يمكن أن تكون المستندات دائمًا أفضل - ومرة ​​أخرى ، سأحب الأفكار الملموسة هناك حول كيفية توصيل الأشياء بشكل أكثر وضوحًا.

التلميح بأنني أدعو الناس بالغباء ليس شيئًا أرغب فيه بعد الآن.

المعنى الضمني لملف خارج rootDir هو أن TS سينتج ملفًا خارج outDir ، والذي أعتقد أنه سلوك سيء بديهيًا.

ما زلت غير واضح بشأن السبب الذي يجعل المترجم لا يقوم فقط بـ "chroot" لـ rootDir ولا يأخذ في الاعتبار الملفات خارج هذا الدليل. كمستخدم ، ربما يفتقر إلى سياق حول tsc الداخلية والتاريخ

أحد الأمثلة التي يمكنني تقديمها من رأسي هو Jest الذي يقدم نفس الخيار: https://jestjs.io/docs/en/configuration#rootdir -string. لا يعتبر AFAIK Jest ملفات الاختبار خارج rootDir . أتوقع نفس السلوك هنا على سبيل المثال.

يمكن أن تكون المستندات دائمًا أفضل - ومرة ​​أخرى ، سأحب الأفكار الملموسة هناك حول كيفية توصيل الأشياء بشكل أكثر وضوحًا.

أنا سعيد لأنك تفكر في إجراء تحسينات هنا. قد يكون اقتراح MicahZoltu ممتعًا للاستكشاف.

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

التلميح بأنني أدعو الناس بالغباء ليس شيئًا أرغب فيه بعد الآن.

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

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

ngryman أوافق على أن تعريف rootDir وما يفعله في الواقع لا يبدو أنه يتماشى. عند إنشاء مشروع ts جديد (عبر tsc --init ) فإن التعليق في tsconfig.json مقابل rootDir يشبه ما نقلته عن /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */ . إذا قدمت دليلًا لملفات _input_ ، فأنا أتوقع أن الملفات الوحيدة التي ستفكر في تجميعها موجودة في هذا الدليل ، من خلال تعريف الإدخال.

RyanCavanaugh قد يكون من المنطقي الإبلاغ عن خطأ مثل هذا منذ 4 سنوات عندما تم استخدام الكتابة المطبوعة فقط ليتم تجميعها في جافا سكريبت. بالطبع لا أريد ملفات مفقودة! ولكن الآن مع شعبية تنفيذ الكتابة المطبوعة ، مثل ts-node ، يبدو أن tsc يشعر بالغيرة قليلاً بالنسبة لي.

والفكرة القائلة بأن الملفات المطبوعة خارج rootDir تشير إلى تكوين غير صحيح للمشروع هي ببساطة فكرة خاطئة. لست بحاجة إلى اختبارات الوحدة الخاصة بي ، والتي تتم كتابتها بخط مطبوع ، ليتم تجميعها في جافا سكريبت. ts-node هو ببساطة أسرع وأستمتع بجميع مزايا الكتابة المطبوعة عند كتابة الاختبارات.

أتفق مع CodySchrank . أنا على ما يرام مع وجود خطأ TS عندما يشير / يستورد ملف مصدر داخل rootDir ملفًا خارجه - وهذا أمر متوقع.

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

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

كان إعداد src / test / out سيناريو رئيسيًا تم تناوله من خلال مراجع المشروع

يتطلب هذا على الأقل تكوين مشروع منفصل لكل مجلد جذر (https://www.typescriptlang.org/docs/handbook/project-references.html). بعد قراءة التعليمات ، خرجت دون فهم جيد لكيفية تنفيذ النمط وأشعر أنني أتلقى مطرقة ثقيلة عندما كان ما طلبته هو طائرة من نوع flyswatter.

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

ما أريد التأكيد عليه هو أن السبب الوحيد لعدم السماح بهذه الميزة يرجع إلى افتراض المترجم لنية الفساد من جانب المطور. عندما يقوم المطور بتعيين "outDir" إلى ./src ويعثر المحول البرمجي على ملف TS في ./test ، يمكن أن يفترض أن هذا الملف لا يحتاج إلى الإرسال (على افتراض أنه بالطبع لم تتم الإشارة إليه من أي ملف في "outDir").

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

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

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

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

حسنًا ، بالنظر إلى هذا أكثر ، أتساءل عما إذا كان هناك نوع من الثبات من جانب الفريق الأساسي الذي يكمن وراء هذه المشكلة:

يجب تجميع كافة التعليمات البرمجية المصدر. إذا لم يتم تجميعها ، فهي ليست شفرة المصدر.

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

بصفتي مستهلكًا لـ TypeScript ، فأنا أفتقر إلى تقدير الصعوبات المحددة في تطبيق مثل هذه الفئة. ومع ذلك ، يبدو أنه يتناسب تمامًا مع "outDir" : أي شيء داخل "outDir" هو جزء من المصدر ، وأي شيء خارجه ولكن داخل مجلد المشروع هو جزء من الكود الداعم. الشيء الرئيسي الذي يجعل هذا مفيدًا / ضروريًا هو ظهور ts-node ، مما يعني أنه يمكنني تنفيذ رمز الدعم هذا كخطوة منفصلة ، مستقلة تمامًا عن التجميع ؛ وبالطبع أريد أن أكون قادرًا على الاستفادة من ذلك.

لم يتم تضمين أي ملفات إدخال تم توفيرها للأداة بشكل ضمني

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

/project/source/index.ts

import '../external.ts'

/project/tsconfig.json

{
  "compilerOptions": {
    "rootDir": "./source"
  }
}

في هذا المثال ، تخبر المترجم أن "ملفات المصدر موجودة فقط في دليل 'المصدر'". ثم يشير أحد هذه الملفات إلى ملف _not_ في الدليل المصدر. يحتوي TypeScript الآن على تعليمتين متضاربتين ، أحدهما ينص على تجميع الملفات فقط في الدليل المصدر ، والآخر يقول لتجميع الملفات خارج الدليل المصدر.

MattiasMartens أنت تخلط ضمنيًا بين include و rootDir . إذا كان لديك /src و /test ، إذا كان include هو src/* فلا يمكنك الحصول على أخطاء حول الأشياء في /test ما لم يكن هناك شيء من استورد src شيئًا ما بشكل غير صحيح من test ، وهو أمر يجب أن تكون سعيدًا به!

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

على أي حال!

بالنظر إلى تعريف rootDir ، عندما يرى TypeScript ملفًا خارج rootDir ، فإنه يحتوي على بعض الخيارات:

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

أنا أعترض بشدة على فكرة أن إصدار برنامج غير عامل يجب أن يكون هو الوضع الافتراضي. إذا كان طلب الميزة هنا هو ببساطة معالجة ملفات .ts الموجودة خارج rootDir كـ .d.ts ، فهذا معقول ، إنه مجرد شيء منفصل عن rootDir المعنى شيء آخر غير rootDir . ماذا تسمي مثل هذا العلم؟

MattiasMartens أنت تخلط ضمنيًا بين include و rootDir . إذا كان لديك /src و /test ، إذا كان include هو src/* فلا يمكنك الحصول على أخطاء حول الأشياء في /test ما لم يكن هناك شيء من استورد src شيئًا ما بشكل غير صحيح من test ، وهو أمر يجب أن تكون سعيدًا به!

هذا صحيح. لقد تعاملت مع include ووجدت أنها تعمل بشكل أفضل مما كنت أعتقد في هذه الحالة ، بما في ذلك مع أدوات VSCode.

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

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

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

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

أنا أعترض بشدة على فكرة أن _emit برنامج غير عامل_ يجب أن يكون الافتراضي.

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

يجدر التكرار: لقد قمت بتعيين rootDir إلى المجلد حيث توجد شفرة المصدر الخاصة بي ، ويلاحظ المترجم رمز TS الآخر في المشروع الذي لا علاقة له بما في rootDir ، ويتوقف! هذا السلوك المحدد لا يساعدني في فهم الكود الخاص بي. إنه ببساطة مزعج.

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

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

إذا كان طلب الميزة هنا هو معالجة ملفات .ts الموجودة خارج rootDir كـ .d.ts

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

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

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

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

ملف "الاختبارات / foo.ts" خارج rootDir 'src'. هل نسيت تعيين نمط "تضمين"؟

تسجيل # 33515

لقد واجهت مشاكل مع هذا ، وكذلك في https://github.com/microsoft/TypeScript/issues/31757#event -2480427393

تم تصميم التفاعل بين rootDir و include و Exclusion بطريقة غريبة جدًا.

لطالما اعتقدت أن rootDir هو المجلد الذي يبدأ المترجم في اجتيازه ويتضمن مجلدات إضافية (مثل مجلدات البائع) التي يمكن الرجوع إليها من rootDir.

التعريف الحالي غريب مثل الجحيم وغير بديهي للغاية.

ومن المفارقات أن الأمر المربك هو أنهم لا يتفاعلون: لا تؤثر الإعدادات على بعضها البعض على الإطلاق. يتحكم include بنسبة 100٪ في ما هو موجود في البرنامج و rootDir 100٪ يتحكم في حساب تخطيط outDir .

فقط لإضافة مثال آخر على المشكلة ، هذا هو هيكل المجلد الخاص بي:

tsconfig.json
package.json
src/index.ts

لدي في tsconfig الخاص بي:

"rootDir": "src",
"outDir": "lib",

وفي ملف "index.ts" (مجلد src)

import pkg from '../package.json'; // I read the package.json object

export class SomeClass {
  public version = pkg.version;
}

أعلم أنه بعد الإنشاء ، سيكون ملف "index.js" داخل مجلد "lib". وأنا أعلم أن package.json سيكون بمستوى واحد لأعلى.
لا أعتقد أن برنامج Typescript يجب أن يعرف بشكل أفضل مني بنية المجلد الخاص بي وأن يكسر البنية. يجب أن يقوم ببساطة بتسجيل تحذير حول بعض الملفات الموجودة خارج مجلد rootDir والتي لم يتم تضمينها في مجلد الإخراج.

sebelga ربما أعتبر أن هناك خطأ - السماح .json من خارج rootDir سيكون مقبولًا لأن TS لا ينسخ ذلك إلى مجلد الإخراج

sebelga ربما أعتبر أن وجود خطأ - السماح بامتداد json من خارج rootDir سيكون على ما يرام لأن TS لا ينسخ ذلك إلى مجلد الإخراج

شكرًا ليس صحيحًا .. لدينا بعض القواعد الخاصة لإرسال ملفات .json ... إذا كان الملف سيُرسل في نفس الموقع في حد ذاته ، فعندئذٍ فقط لا يتم إرساله. في جميع الحالات يتم إرساله (على سبيل المثال عند تحديد --outDir ، سيتم إرساله إلى هذا المجلد)

RyanCavanaugh لديّ حالة استخدام مماثلة لـ sebelga حيث أريد console.log من رقم الإصدار من package.json في وقت التشغيل.

لذلك كان الحل هو تغيير "rootDir": "." ، ثم لدي هذا يشمل

"include": [
    "src",
    "typings"
  ]

ونظرًا لتضمين الملف package.json في المجلد lib (المدمج) ، الذي يحتوي على مجلد فرعي "src" ، فقد كتبت نصًا برمجيًا يعمل مباشرة بعد الإنشاء لتنظيف الأشياء.

#!/bin/bash

rm lib/package.json
mv $(pwd)/lib/src/* $(pwd)/lib
rm -rf lib/src

إنه يعمل ، لكنه يشعر بأنه مبتذل جدًا بالنسبة لي.

sebelga هل لديك ملفات .ts في المجلد typings ؟ إذا لم يكن الأمر كذلك ، فسيكون قانونيًا تعيين rootDir على src وتخط النص.

sebelga بدلاً من const { version } require('../../package.json') أو import { version } from 'package.json') ، هل حاولت فعل شيء مثل هذا:

import { sync as loadJsonFileSync } from 'load-json-file';

const { version } = loadJsonFileSync('../../package.json');

لن يهتم TypeScript بكونه خارج rootDir بهذه الطريقة.

https://github.com/sindresorhus/load-json-file

إذا كنت تريد تجنب تشفير جميع الـ ../.. يمكنك تجربة هذا:
https://github.com/sindresorhus/read-pkg-up

RyanCavanaugh لا يمكنني تعيينه على "src" كما هو مذكور أعلاه. أقوم باستيراد "package.json" خارج src ( import pkg from '../package.json'; ) ولا يسمح tsc بذلك.

شكرا لتقاسم هذا dylang ! سأجربه.

أخبرت مطبعيًا أن مصدري كان كله في مجلد معين (عبر rootDir)

ليس هذا ما يعنيه rootDir ! يعني rootDir "استخدم هذا المجلد كأساس نسبي لحساب المسارات في outDir ". _ما هي الملفات التي تشكل جزءًا من التجميع الخاص بك_ هو سؤال منفصل يتم الإجابة عليه بواسطة files و / أو include / exclude

RyanCavanaugh لكن هذا ما يجب أن يعنيه rootDir ، وهذا ما تدور حوله هذه المشكلة.

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

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

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

إنه هذا الصراع ، هذا الجدل ، الذي استمر لسنوات حول ما يبدو أنه تعريف الخاصية "rootDir". وماذا تفعل حيال هذه القضية.

يتم إلقاء الناس في هذا النقاش لأنهم يعتقدون أنهم على حق. نعم ، يعمل "rootDir" كدليل أساسي لكود المصدر. نعم ، الخطأ صحيح.

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

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

هل يمكننا العمل معًا وحل هذه المشكلة من فضلك؟ سأجعلني سعيدًا جدًا برؤية تلك الخطوط الحمراء تختفي ...

nullquery إذا كان tsc يعمل ولكن IDE الخاص بك يعرض خطوط متعرجة حمراء ، فهذا يعني أن IDE الخاص بك لا يستخدم نفس إصدار المجمع أو التكوين مثل tsc .

nullquery ملف خطأ يوضح كيفية إعادة إنشاء المشكلة وسنقوم إما بإصلاحها أو إخبارك بالخطأ في تكوين مشروعك

متابعة من الحل البديل

tsc --module commonjs --target ESNext --outDir ./edition-esnext --project tsconfig.json && test -d edition-esnext/source && ( mv edition-esnext/source edition-temp && rm -Rf edition-esnext && mv edition-temp edition-esnext ) || true

مثال على الاستخدام هنا.

سيطبق Boundation لك تلقائيًا.

الحل هو مراجع المشروع .

لاستخدام هذا ، قم بتحرير ملف "tsconfig.json" وأضف هذا إلى نهاية الملف (خارج "compilerOptions"):

"references": [
    { "path": "../common" }
]

سيسمح لك هذا بالرجوع إلى الملفات الموجودة في المجلد "../common/" (وجميع المجلدات الفرعية).

كان ارتباكي السابق ينبع من حقيقة أن IntelliJ ومهمتي gulp-typescript الملوثة أعطاني نتائج مختلفة على الرغم من استخدام نفس ملف "tsconfig.json".

اتضح أنه لسبب ما ، تحاول "gulp-typecript" محاولة أفضل نهج للترجمة.

سيتم وضع علامة على خطأ في TypeScript (مثل let z: number = '' ) في IntelliJ ولكن "gulp-typecript" يجمعها بشكل جيد.
يتم تمييز أخطاء بناء جملة JavaScript فقط (مثل let 1z = '' ) بواسطة "gulp-typescript".

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

أعلم أن استخدام مراجع المشروع مدفون في مكان ما في هذا الكم الهائل من الردود ، ولكن كان من الأفضل لو تم توثيق ذلك بشكل أفضل.

تؤدي أفضل 3 نتائج لـ "TS6059" على Google جميعها إلى مشكلات في GitHub. كان من الممكن أن يكون الأمر أكثر وضوحًا بالنسبة لي لو كانت هناك صفحة توثق هذه الأخطاء الشائعة وحلولها.

MicahZoltu هل هذا شيء يمكن معالجته؟ هل يجب أن أقوم بإصدار عدد جديد ، أم أنه من شأنه أن يسير بشكل أسرع إذا تمت مناقشته داخليًا بين المساهمين الرئيسيين؟

(FWIW أنا لست جزءًا من فريق TypeScript)

بشكل عام ، أوصي بعدم استخدام path s إلا إذا كنت مضطرًا لذلك. أعتقد أن الغرض منه هو السماح بالتوافق مع مشاريع JS القديمة ذات هياكل التبعية الغريبة ، لكنني لا أعتقد أن الغرض منها هو استخدامها في أي مشاريع جديدة ، وإذا وجدت نفسك في حاجة إليها ، فقد ترغب في التفكير في الترحيل بعيدًا عنها عندما لديك الفرصة. لا أستخدمه شخصيًا ، لذا لا يمكنني فعلاً المساعدة في المشكلات التي قد تواجهك بها ، لكنني رأيت الكثير من الأشخاص يعانون من ذلك ، والحل عادةً هو "التوقف عن استخدامه".

بالنسبة إلى gulp-typecript ، يبدو أن إصدار TSC المستخدم بواسطة gulp-typecript مختلف عن إصدار TSC الذي تستخدمه IntelliJ. عندما ترى أعراضًا مثل التي وصفتها ، فعادة ما تكون هذه هي المشكلة (والآخر هو أنهم لا يستخدمون نفس tsconfig.json ).

يجب أن تكون النسخة المستخدمة بواسطة "gulp-typecript" متطابقة ؛ كلا الإصدارين مستمدان من node_modules . لقد جربت طرقًا مختلفة لاكتشاف الأخطاء وتعديل الإعدادات المتعلقة بها (بما في ذلك العبث مع "المراسلين" المختلفين المقدمين من "gulp-typecript" ومحاولة تجاوز الإعدادات لإصدار المزيد من الأخطاء. يبدو أن لا شيء يعمل.

لا بأس رغم ذلك. طالما أن IntelliJ يعطيني أخطاء ، يسعدني أن أقبل أن مهمة Gulp ستتجاهلها.

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

لا أؤمن "بالسماح بالتوافق لأسباب قديمة" ، وخاصة عندما يتعلق الأمر بمراجع المشروع. _يجب_ أن يكون من الممكن الرجوع إلى الملفات خارج rootDir وإلا فلن تتمتع بحرية تحديد هيكل المشروع بطريقة منطقية لك وللفريق الخاص بك.

عندما بدأت العمل مع TypeScript لأول مرة ، واجهت العديد من المشكلات. بينهم:

• لتضمين ملفات JavaScript ، بدا أن حل go-to هو AMD في ذلك الوقت. بدا موقع الويب رسميًا وكان هناك العديد من الأمثلة عبر الإنترنت على AMD في استخدام الإنتاج. ولكن على ما يبدو ، كان Webpack هو الشيء الكبير الجديد ولذا فإن بعض المشاريع لم تنجح في بيئة AMD. الدرس المستفاد: لن يتبنى الجميع الطريقة الجديدة ، لذلك فأنت دائمًا في حالة من الفوضى.

• لم يكن الطريق من TypeScript إلى JavaScript المصغر النهائي (مع تعيينات المصدر) واضحًا بالنسبة لي. كانت هناك عدة طرق مختلفة متاحة في ذلك الوقت ، ولكن لا يبدو أن أيًا منها يعمل بشكل أصلي مع ملفات "tsconfig.json" و / أو IDE الخاص بي في ذلك الوقت. تعلمت الدرس: إذا كنت تريد القيام بشيء ما بشكل صحيح ، فعليك أن تفعله بنفسك ؛ لا تعتمد على أشخاص آخرين للقيام بالعمل نيابة عنك ، بغض النظر عن مدى حسن نواياهم ، فلا أحد مثالي ولا يمكن لأحد التنبؤ بمساحة عملك.

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

انتهى بي الأمر إلى تطوير ملف Gulpfile الخاص بي للتعامل مع كل شيء. يقوم بما يلي:

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

• يجمع TypeScript وفقًا لملف "tsconfig.json" المحلي الذي ينشئ ملفات منفصلة في دليل الإخراج (باستخدام outDir ) لذلك يمكنني التأكد من أن TypeScript يتم تجميعها بنفس الطريقة في IDE الخاص بي كما هو الحال في Gulp (hahahahaha!) ، ثم يستخدم البرنامج المساعد "rollup" لضغط هذه الملفات في ملف JavaScript واحد ، ثم يقوم بتشغيل UglifyJS لتصغير هذا الملف ، مع الحفاظ على تعيين المصدر الذي يعيد تعيينه إلى ملف TypeScript الأصلي.

• (مهمة مخصصة) يولد ملف JavaScript يحتوي على قاموس يسمى html_templates لكل ملف HTML في جذر مصدر TypeScript ويضعه في مجلد webroot الخاص بي كملف JavaScript مصغر.

قد تكون هناك طرق أكثر أناقة ، ولكن بعد القفز من مشروع مفتوح المصدر إلى آخر ، كان لدي ما يكفي من التلاعب بين الحلول التي يقدمها كل منهم.

النهج الذي اخترته يعمل ، إنه بسيط بما يكفي لفهمه (خاصة الآن بعد أن فهمت أن "gulp-typecript" تفعل شيئًا مختلفًا) وسأستمر على الأرجح في استخدام هذا لسنوات قادمة.

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

TL ؛ دكتور من فضلك لا تكسر مراجع المشروع. أحتاج ذلك لكي تعمل أدواتي. اشكرك

لقد تخليت عن إعداد إعداد TS متعدد المشاريع بشكل احترافي وقمت فقط بعمل tsc -w في كل مشروع و npm link ، وبعد ذلك يمكنك فقط تجاهل جميع تعقيدات tsconfig متعدد المشاريع والرجوع فقط إلى الآخر مشروع مثل تبعيات node.js العادية في node_modules .

لكن اليوم في مشروع واحد قمت بتغيير الهدف من es5 إلى es6 ولن يتم تجميعه بعد الآن بسبب File '.../lib.ts' is not under 'rootDir' .

هيكل الملف:

/app
 - tsconfig.json // rootDir = "."
 - app.ts (

/app/node_modules/lib
 - tsconfig.json // rootDir = "."
 - lib.ts
 - lib.js
 - lib.d.ts

لماذا يهتم tsc في /app بحوالي /app/node_modules/lib/lib.ts ملف؟ لا ينبغي أن يستخدم هذا الملف على الإطلاق. تم تجميعها /app/node_modules/lib/lib.js و /app/node_modules/lib/lib.d.ts .

إذا تم حذف /app/node_modules/lib/lib.ts - مفاجأة - فسيكون ذلك جيدًا.

alexeypetrushin يمكنك إلقاء نظرة على بعض

• https://github.com/unional/standard-log
• https://github.com/mocktomata/mocktomata

import * as pkg from '../package.json';

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

SephReed : لقد أنفقت 200 نقطة مندوب على StackOverflow وساهم أحد الأشخاص بهذا الحل البسيط جدًا لاستيراد ../package.json . كل ما عليك فعله هو وضع ملف typings.d.ts في نفس الدليل مثل package.json ، بهذه المحتويات:

declare module '*.json';

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

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

repo/
⊢ config/  << provide TS support, but don't build this directory
  ⨽ webpack.config.ts 
⊢ scripts/  << provide TS support, but don't build this directory
  ⨽ release.ts
⊢ src/        << build this directory
  ⨽ example.ts
⨽ tsconfig.json

لذا أستخدم "rootDir": "src" للتأكد من أن الملفات موجهة إلى dist وليس إلى dist/src . لكن بالطبع ، يحب TypeScript تقديم شكوى بشأن هذا الإعداد ، لكن بما أنني أستخدم Webpack ، فإنه لا يخطئ بالنسبة لي.

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

الخيارات التي تحدد المجلدات والملفات الخاصة بـ tsc لمراعاة التوافق: "الملفات" ، "تشمل" ، "استبعاد".

ثم ماذا تستخدم ل "rootDir"؟
rootDir هو جذر بنية الدليل (التسلسل الهرمي) لملفات المصدر الخاصة بك ، والتي يستخدمها tsc لإصدار نفس بنية الدليل بدءًا من دليل tsconfig.json أو "outDir" إذا كان محددًا. لذلك ليس هذا هو المسار الذي يستخدمه tsc كمسار أساسي لـ "outDir". "outDir" هو فقط الجذر الذي يرسل tsc ملفات الإخراج.
على سبيل المثال ، لنفترض أن مشروع جافا الخاص بك يحتوي على بنية الدليل هذه.

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

عند تعيين "include" و "rootDir" على النحو التالي ، فإن tsc سينشئ الإخراج على النحو التالي:

"include": "src/main/resources/static/ts" *
"rootDir": "." *

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.js *
          test.ts

عندما تقوم أيضًا بتعيين "outDir" على النحو التالي ، فسيقوم tsc بإنشاء الإخراج على النحو التالي:

"include": "src/main/resources/static/ts"
"rootDir": "."
"outDir": "build" *

- build
  - src
    - main
      - resources
        - static
          - ts
            test.js *
- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

ربما كنت ترغب في الحصول على هذا عن طريق تعيين خيار "rootDir" وتغيير خيار "outDir" كما هو موضح أدناه.

"include": "src/main/resources/static/ts"
"rootDir": "src/main/resources/static/ts" *
"outDir": "src/main/resources/static/js" *

- src
  - main
    - java
    - resources
      - static
        - js
          test.js *
        - ts
          test.ts

لذلك عندما تقوم بتعيين خيار "rootDir" الذي لا يغطي نطاقات الملفات باستثناء خيار "استبعاد" ، يفشل tsc في الإنشاء لأنه لا معنى له مع الغرض من خيار "rootDir".

نعم ، إنها ممارسة تسمية سيئة تمامًا. كان يجب أن يكون مجرد "rootOfStructureOfInputs" أو شيء من هذا القبيل. وأيضًا ، كان يجب أن تكون "outDir" مجرد "rootOfOutputs".

ما تراه على SS ليس مشكلة WebStorm - إنه يأتي من TS DevServer.
الاستيراد الثاني الموصى به هو حماقة. يتم التقاطها من مجلد مصدر "الاتصالات". لا أعرف من يجب أن يريد ذلك. ينتج عن تجميع ملف بهذا الاستيراد مجموعة من المشاكل.

حاولت أيضًا:

"exclude": ["lib", "node_modules",
        "..", "../..", "../../..", "../../../..", "../../../../..", "../../../../../.."
    ]

لم تحل المشكلة أيضًا

mhegazy لقد سميت هذه المشكلة بعبارة "العمل بالشكل