Tslint: التبعيات غير الضمنية: دعم تخطيط المسار

أعتقد أنه إذا لم يتم حل عملية الاستيراد لشيء ما في node_modules ، فيجب أن تتجاهل هذه القاعدة ذلك.

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

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

في حالتنا ، لا يوجد بشكل عام package.json على الإطلاق ، لذا أعتقد أنه يجب علينا تعطيل هذه القاعدة بعد ذلك. شكرا!

في حالتي ، أنا "أستورد" مشاريع منفصلة للرموز المطبوعة أعمل عليها في نفس الوقت باستخدام تعيين المسار:

"compilerOptions": {
    ...
    "paths": {
        "tsbase": ["../tsBaseProject/src"],
        "tslibrary": ["../tsProjectLibrary/src"]
    }
}

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

تعيينات مسار marcoqu ذات صلة فقط في وقت الترجمة. في وقت التشغيل ، يجب أن توجد هذه الوحدات في node_modules. أقترح إضافتها إما كـ dependencies أو peerDependencies إلى الحزمة الخاصة بك. json

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

+1 لإضافة قائمة بيضاء كما هو الحال في عمليات الاستيراد بدون وحدة فرعية

لدينا أيضًا الحالة التي نستخدمها في الحالة التي نحدد فيها اسمًا مستعارًا للمسار "~" للقاعدة dir لتجنب عمليات الاستيراد النسبية. تم حل هذا الاسم المستعار لاحقًا عن طريق حزمة الويب ، صندوق المصاهر ، إلخ. بدءًا من 5.8 ، يقوم tslint بإخراج الكثير من الأخطاء الزائفة بسبب هذا ...

ما قاله ^ ^

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

لا تعمل هذه القاعدة عندما نستخدم الاسم المستعار لشفرة المصدر الخاصة بنا (وليس للاستيراد من حزم npm). من المفيد جدًا استخدام المسار المطلق بدلاً من المسار النسبي.
في tsconfig.json الخاص بنا ، بالنسبة للتطبيق الزاوي ، علينا فقط إضافة:

"compilerOptions": {
  ...
  "baseUrl": "./src",
  "paths": {
    "~/env": ["environments/environment"],
    "~/*": ["app/*"]
  }
}

ثم يمكننا القيام بعمليات الاستيراد مثل:

import {FooService} from '~/core';
import {Environment} from '~/env';

ربما يتعين علينا إعادة فتح هذه المشكلة لحل هذه الحالة (ليست هناك حاجة إلى node_modules ، فقط ملف tsconfig.json).
أنا أقدر هذه القاعدة ، لذلك سيكون من المؤسف تعطيلها.

@ andy-ms ، يرجى إعادة النظر في دعم المسارات (نستخدمه على نطاق واسع مع مساحات عمل nx). هذه قاعدة مفيدة حقًا ، لكنني مضطر الآن إلى تعطيلها.

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

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

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

أضف حزمة وهمية إلى optionalDependencies مع اسم خريطة المسار من tsconfig.json ، وقم بتثبيت التبعيات باستخدام npm install --no-optional . هذا للأسف لا يعمل مع yarn --ignore-optional - إنه فشل في محاولة جلب الحزمة.

لذلك ، مع المسارات في tsconfig.json تبدو شيئًا كالتالي:

    "paths": {
        "~/*": ["src/*"],
        "some-path/*": ["whatever/*"]
    }

واختياري في package.json مثل هذا:

    "optionalDependencies": {
        "~": "tslint-hack",
        "some-path": "tslint-hack"
    },

يجب أن يكون من الممكن تثبيت تبعيات الإنتاج والتطوير باستخدام npm install --no-optional . من الواضح أن هذا يفترض أنك لست بحاجة إلى تثبيت أي تبعيات اختيارية. تجدر الإشارة أيضًا إلى أنني لم أجدها تعمل مع @ كاسم الحزمة.

إذا اخترت استخدام هذا الاختراق ، فربما يكون من الذكاء إضافة ملف .npmrc إلى جذر المشروع ، مع تكوين optional=false ، بحيث يمكنك العودة إلى تشغيل npm install بدون العلم --no-optional .

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

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

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

أعتقد أن هذا طلب صالح لأن tslint هو كل شيء عن الكتابة المطبوعة والمسارات هي إعداد مطبوع (ومهم) صالح للطباعة.

ماذا لو كان لديّ package.json في دليل مختلف عن الدليل tslint.json ؟

- web
    - package.json
    - ClientApp
        - tslint.json

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

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

"no-implicit-dependencies": [true, ["src", "app", "~"]]

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

بالنسبة لأولئك منا الذين يستخدمون رموز @ كبادئات للمسارات المخصصة ، قمت برفع العلاقات العامة لإصلاح خطأ صغير في التطبيق الحالي # 4192

"no-implicit-dependencies": [true, ["@src", "@app", "~"]]

ifiokjr كنت أستخدم @ كاسم src المستعار الخاص بي ، لذا بدت الواردات مثل @/components
تعذر تعيين @ كمسار تم تجاهله نظرًا لأنه حاول استيراد @/components كوحدة نمطية كاملة بدلاً من حل @ أولاً.

لقد غيرت اسمي المستعار إلى ~ واستخدمت السطر أعلاه في tslint الخاص بي ، وحل المشكلة