Tslint: गैर-अंतर्निहित-निर्भरता: समर्थन पथ मानचित्रण

को निर्मित 20 अक्तू॰ 2017 · 18टिप्पणियाँ · स्रोत: palantir/tslint

बग रिपोर्ट

__TSLint संस्करण__: 5.8.0
__टाइपस्क्रिप्ट संस्करण__: 2.7.0-देव.20171020
__TSLint के माध्यम से चल रहा है__: CLI

टाइपस्क्रिप्ट कोड पंक्तिबद्ध किया जा रहा है

src/a.ts

import { x } from "foo";

प्रकार/foo.d.ts

export const x = 0;

tsconfig.json

{
    "compilerOptions": {
        "paths": {
            "*": "types/*"
        }
    }
}

tslint.json कॉन्फ़िगरेशन के साथ:

{
    "rules": {
        "no-implicit-dependencies": true
    }
}

वास्तविक व्यवहार

ERROR: /home/andy/sample/tslint/src/a.ts[1, 19]: Module 'foo' is not listed as dependency in package.json

अपेक्षित् व्यवहार

कोई त्रुटि नहीं। मुझे लगता है कि अगर किसी आयात को node_modules किसी चीज़ के लिए हल नहीं किया जाता है तो इस नियम को इसे अनदेखा करना चाहिए।

स्रोत

andy-ms

👍15

सबसे उपयोगी टिप्पणी

यह नियम तब काम नहीं करता जब हम अपने स्वयं के स्रोत कोड के लिए उपनाम का उपयोग करते हैं (एनपीएम पैकेज से आयात नहीं करने के लिए)। सापेक्ष पथ के बजाय निरपेक्ष पथ का उपयोग करना बहुत उपयोगी है।
हमारे tsconfig.json में, कोणीय अनुप्रयोग के लिए, हमें बस जोड़ना है:

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

तब हम आयात कर सकते हैं जैसे:

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

हो सकता है कि हमें इस मामले को हल करने के लिए इस मुद्दे को फिर से खोलना चाहिए (नोड_मॉड्यूल्स की कोई आवश्यकता नहीं है, बस tsconfig.json फ़ाइल)।
मैं इस नियम की सराहना करता हूं, इसलिए इसे अक्षम करना दुर्भाग्यपूर्ण होगा।

fredgate 26 जन॰ 2018

👍48 ❤2

सभी 18 टिप्पणियाँ

मुझे लगता है कि अगर नोड_मॉड्यूल्स में किसी चीज़ के लिए कोई आयात हल नहीं होता है तो इस नियम को इसे अनदेखा करना चाहिए।

नियम मॉड्यूल को हल करने का प्रयास नहीं करता है। इसका मतलब यह होगा कि आपको सभी निर्भरताओं को स्थापित करने की आवश्यकता है, जो वास्तव में सहकर्मी निर्भरता और वैकल्पिक निर्भरता के साथ संभव नहीं है। वर्तमान कार्यान्वयन के साथ आप कुछ भी स्थापित किए बिना एक नया क्लोन बना सकते हैं। मुझे लगता है कि अधिकांश कोड गुणवत्ता उपकरण यही करते हैं।

जैसा कि मैं पथ मैपिंग को समझता हूं, वे केवल संकलन समय पर मौजूद होते हैं। रनटाइम पर आपको अभी भी नोड/वेबपैक/जो कुछ भी सही ढंग से लेने के लिए स्थापित मॉड्यूल की आवश्यकता है।
इसका मतलब है कि पथ मैपिंग केवल तभी प्रासंगिक होती है जब आपके पास केवल ऐसे आयात होते हैं जो संकलन के दौरान समाप्त हो जाते हैं। इस मामले में नियम शायद आपके लिए सही विकल्प नहीं है।

ajafff 20 अक्तू॰ 2017

हमारे मामले में आम तौर पर कोई package.json होता है, इसलिए मुझे लगता है कि हमें इस नियम को तब अक्षम कर देना चाहिए। धन्यवाद!

andy-ms 20 अक्तू॰ 2017

😕3

मेरे मामले में, मैं अलग-अलग टाइपप्रति परियोजनाओं को "आयात" कर रहा हूं, मैं पथ मानचित्रण का उपयोग करके एक साथ काम कर रहा हूं:

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

ताकि मैं उन्हें परियोजना में उपयोग कर सकूं जैसे कि वे मॉड्यूल थे।
क्या उन्हें श्वेतसूची में डालने का कोई तरीका है?

marcoqu 24 अक्तू॰ 2017

👍2

@marcoqu पथ मैपिंग केवल संकलन समय पर प्रासंगिक हैं। रनटाइम पर इन मॉड्यूल को नोड_मॉड्यूल में मौजूद होना चाहिए। मेरा सुझाव है कि उन्हें अपने पैकेज में dependencies या peerDependencies के रूप में जोड़ें।

ajafff 24 अक्तू॰ 2017

जब मैं मुख्य स्रोत को संकलित करता हूं जो माध्यमिक परियोजनाओं को "आयात" करता है, तो सब कुछ एक बंडल में संकलित किया जाता है जैसे कि वे परियोजना में वास्तविक फ़ोल्डर थे। मुझे उन्हें node_modules फ़ोल्डर में रखने की आवश्यकता नहीं है।
स्पष्ट होने के लिए, द्वितीयक प्रोजेक्ट फ़ोल्डर्स में मेरे पास वास्तविक .ts फ़ाइलें हैं, न केवल प्रकार की घोषणाएं।

marcoqu 24 अक्तू॰ 2017

श्वेतसूची जोड़ने के लिए +1 जैसे नो-सबमॉड्यूल-आयात

jmolero 27 अक्तू॰ 2017

👍31

हमारे पास यह भी मामला है कि हम मामले का उपयोग करते हैं कि हम सापेक्ष आयात से बचने के लिए आधार डीआईआर में पथ उपनाम '~' परिभाषित करते हैं। इस उपनाम को बाद में वेबपैक, फ़्यूज़-बॉक्स, आदि द्वारा हल किया जाता है। 5.8 से शुरू होकर, tslint इस वजह से बहुत सारी नकली त्रुटियां निकालता है...

mika-fischer 9 नव॰ 2017

👍21

उसने क्या कहा ^^

rkrupinski 12 नव॰ 2017

👍4

अपग्रेड करने के बाद अब मेरे पास उपरोक्त उल्लिखित कारणों के लिए इनमें से सैकड़ों त्रुटियां हैं। एक तरह का व्यर्थ नियम।

vancityhuddy 20 नव॰ 2017

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

तब हम आयात कर सकते हैं जैसे:

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

fredgate 26 जन॰ 2018

👍48 ❤2

@ एंडी-एमएस कृपया सहायक पथों पर पुनर्विचार करें (हम इसे एनएक्स वर्कस्पेस के साथ बड़े पैमाने पर उपयोग करते हैं)। यह वास्तव में उपयोगी नियम है, लेकिन अभी के लिए मैं इसे अक्षम करने के लिए मजबूर हूं।

chris5287 19 फ़र॰ 2018

मैंने स्रोत कोड को देखने की कोशिश की और फिक्स को इन पंक्तियों के साथ कहीं जाना होगा । मैंने यह भी जांचा है कि टाइपस्क्रिप्ट इसे कैसे संभाल रहा है और मैंने इसे इस फ़ंक्शन पर ट्रैक किया

FredyC 24 फ़र॰ 2018

👍1

मैं इसे भी ठीक होते हुए देखना चाहता हूं। पथ मानचित्रण एक अत्यधिक मूल्यवान विशेषता है। मैंने लिंक किए गए मॉड्यूल को वर्कअराउंड के रूप में उपयोग करने का भी प्रयास किया, लेकिन वे भी समर्थित नहीं हैं।

मैंने एक वर्कअराउंड का पता लगाया जो मेरे लिए कुछ हद तक इस मुद्दे को हल करता है, लेकिन यह निश्चित नहीं है कि यह सभी के लिए होगा, या यह बिल्कुल भी बनाए रखने योग्य है। वैसे भी, समाधान इस प्रकार है:

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_ काम वास्तव में वांछित नाम के साथ एक पैकेज बनाना और इसे एक निजी रजिस्ट्री में प्रकाशित करना, करना है । मैं मानता हूं कि .npmrc या .yarnrc का उपयोग करके प्रति मॉड्यूल निजी रजिस्ट्रियों को कॉन्फ़िगर करना संभव है, और इस तरह रखरखाव के मामले में बेहतर होना चाहिए। हालांकि इनमें से किसी का भी परीक्षण नहीं किया जाता है।

आशा है कि यह उन लोगों के लिए थोड़ी मदद कर सकता है जो इस tslint नियम का उपयोग करना चाहते हैं और अपने मॉड्यूल संकल्पों को जगह में रखना चाहते हैं। लेकिन यह एक उचित फिक्स का कोई विकल्प नहीं है..

tdolsen 28 मार्च 2018

इसके अलावा यह समस्या है, जिसके परिणामस्वरूप सोनार ने इसे गलत तरीके से कोड गंध के रूप में चिह्नित किया है।

josecolella 27 अप्रैल 2018

👍1

मुझे लगता है कि यह एक वैध अनुरोध है क्योंकि tslint टाइपस्क्रिप्ट के बारे में है और पथ एक वैध (और महत्वपूर्ण) टाइपस्क्रिप्ट सेटिंग हैं।

a7madgamal 13 सित॰ 2018

क्या होगा यदि मेरे पास package.json तुलना में किसी भिन्न निर्देशिका में tslint.json ?

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

मैं एक समान सेटअप पर काम कर रहा हूं और इस नियम के कारण मुझे लगभग सभी फाइलों में त्रुटियां मिल रही हैं। इसके लिए कोई उपाय?

omkar-joshi 14 सित॰ 2018

जिस तरह से मैंने इस समस्या को हल करने के लिए पाया है वह निम्न कॉन्फ़िगरेशन विकल्प का उपयोग कर रहा है।

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

यह प्रदान किए गए पथों को श्वेतसूची में रखता है। जाहिर है, इसका मतलब दोहराव है लेकिन अगर आप एक की तलाश कर रहे हैं तो यह एक त्वरित समाधान है।

हममें से जो कस्टम पथ के लिए उपसर्ग के रूप में @ प्रतीकों का उपयोग करते हैं, उनके लिए मैंने वर्तमान कार्यान्वयन #4192 के साथ एक छोटी सी बग को ठीक करने के लिए एक पीआर उठाया है

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

ifiokjr 27 सित॰ 2018

👍16 ❤15 🚀1

@ifiokjr मैं अपने स्रोत उपनाम के रूप में @ का उपयोग कर रहा था, इसलिए मेरा आयात @/components जैसा दिखता था
सेट नहीं हो सका @ पर ध्यान नहीं दिया पथ के रूप में के बाद से इसे आयात करने की कोशिश की @/components बजाय हल करने की एक पूरी मॉड्यूल के रूप में @ पहले।

मैंने अपने उपनाम को ~ बदल दिया और समस्या को हल करते हुए अपने tslint में उपरोक्त पंक्ति का उपयोग किया

marcosfede 6 जून 2019

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स