Less.js: डेटा-यूरी फ़ंक्शन डेटा-यूरी कॉल के पथ का उपयोग करता है, न कि फ़ाइल के पथ के साथ स्ट्रिंग का।

मैं इस पर प्रतिक्रिया का स्वागत करता हूं कि क्या यह एक ब्रेकिंग बदलाव है (एक प्रमुख अप की गारंटी) या एक बग फिक्स।

FYI करें: आप बहुत ही सरल तरीके से पीछे की ओर-संगतता को तोड़े बिना इसे सुरुचिपूर्ण ढंग से लागू कर सकते हैं।

वर्तमान में data-uri() फ़ंक्शन फ़ाइल पथ के रूप में एक स्ट्रिंग धारण करने वाले Quoted ट्री नोड को स्वीकार करता है और फ़ंक्शन कॉल रखने वाली फ़ाइल के स्थान के विरुद्ध URL के रूप में इसे आंतरिक रूप से हल करता है। आप data-uri फ़ंक्शन को एक वास्तविक URL वाले Url ट्री नोड को भी स्वीकार करने के लिए अधिभारित कर सकते हैं। इस तरह URL को उस स्थान के विरुद्ध सामान्यीकृत करना चाहिए जहां url() CSS फ़ंक्शन को कॉल किया जाता है और अब इसे data-uri() कम फ़ंक्शन में आंतरिक रूप से सामान्यीकृत नहीं किया जाना चाहिए।

उदाहरण के लिए

// app/content/button.less
button {
  .background(url("images/btn.jpg"));
}

@rjgotten

मेरे लिए यह एक फिक्स के बजाय वर्कअराउंड की तरह दिखता है। आगे की पुनरावृत्ति पर वे url को मिक्सिन में ले जाकर वर्बोसिटी से बचने की कोशिश करते हैं और समस्या फिर से आती है। दूसरी समस्या यह है कि मूल उपयोग-मामला लेना जहां यह समस्या (# 2541) से आई है, इसे अक्सर इस तरह इस्तेमाल किया जाता है:

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

(उदाहरण के लिए एक फॉन्ट-फेस मिक्सिन के लिए एक उदाहरण के रूप में यह आमतौर पर कई woff , ttf , eot , eot?#iefix आदि एक ही फ़ाइल नाम से जुड़े एक्सटेंशन ) और इस तरह पहले वाला url भी असंभव है।

@ सात-चरण-अधिकतम

तब मुझे नहीं लगता कि कोई उपयुक्त समाधान अवधि है। आपको उस संदर्भ को निर्धारित करने का कोई तरीका चाहिए जिसके विरुद्ध एक सापेक्ष URL को हल करना चाहिए। या तो आप उस संदर्भ को उस फ़ाइल की फ़ाइल जानकारी से लेते हैं जो data-uri() फ़ंक्शन में जाने वाले स्ट्रिंग मान को परिभाषित करती है, या आप url() फ़ंक्शन और Url ट्री नोड।

यदि आप पथ चर प्रतिस्थापन का समर्थन करना चाहते हैं, तो चीजें जल्दी से मुश्किल हो जाती हैं क्योंकि आपको यह पता लगाने की आवश्यकता होती है कि पथ के विभिन्न हिस्सों को कैसे सामान्य किया जाना चाहिए।

उदाहरण के लिए, आप कुछ सामान्य कैसे करते हैं:

// mixins.less
.background(@image) {
    background-image: data-uri("../../@{image}.jpg");
}
// app/content/button.less
button {
  .background("../images/btn");
}

आप उन दो पथों के सापेक्ष url रिज़ॉल्यूशन और टोकन प्रतिस्थापन-संचालित संयोजन को कैसे संयोजित करेंगे?

मुझे लगता है कि एक विकल्प केवल उस स्ट्रिंग को परिभाषित करने वाली फ़ाइल के विरुद्ध हल करना है जिसे एक प्रतिकृति टोकन के लिए प्रतिस्थापित किया जा रहा है, जब प्रतिकृति टोकन अंतिम यूआरएल मान के शीर्ष पर url() या data-uri() फ़ंक्शन और उपरोक्त जैसे मामलों को अनदेखा करें। यह सबसे तार्किक लगता है।

एक अन्य समाधान पथ में शामिल होने या फ़ाइल एक्सटेंशन जोड़ने/निकालने/संपादित करने के लिए कुछ पथ प्रबंधन कार्यों को पेश करना हो सकता है (इसी तरह unit() फ़ंक्शन आयामों के लिए कैसे काम करता है, हो सकता है?) और चीजों को और स्पष्ट करें।

उदाहरण के लिए

// mixins.less
.background(@image) {
    background-image: data-uri(extension(<strong i="21">@image</strong>, "jpg"));
}
// app/content/button.less
button {
  .background(url("./images/btn"));
}

आपके पहले उदाहरण के लिए, इसे किसी विशेष सामान्यीकरण की आवश्यकता नहीं है, "../../@{image}.jpg" विस्तार "../../../images/btn.jpg" है जैसा कि लिखा गया है (और फिर पथ को संभालने के लिए यह data-uri तक है)।
और दूसरा उदाहरण बस है... किसी फ़ंक्शन को स्टैकिंग करना किसी फ़ंक्शन को वर्कअराउंड करने के लिए बैकवर्ड-कम्पैटिबिलिटी के साथ वर्कअराउंड करने के लिए... वास्तव में क्या? अन्य फ़ाइल में परिभाषित मिक्सिन को कॉल करते समय _गलत_ फ़ाइल पथ?

आखिरकार अगर इसे "उम्मीद के मुताबिक" _only_ .background(url("images/btn.jpg")); साथ काम करना चाहिए, तो यह बिना किसी बदलाव के सीधे .background(data-uri("images/btn.jpg")); लिखने से कैसे अलग है? :)

दूसरे शब्दों में मेरा मतलब यह है कि अगर इसे ठीक करना है तो इसे data-uri साथ तय किया जाना चाहिए, चाहे वह कितना भी टूट जाए। (ईमानदारी से मुझे नहीं पता कि एक बेहतर रणनीति क्या होगी: ए। इसके लिए और रिपोर्ट/अनुरोधों की प्रतीक्षा करें और फिर (यदि उनमें से पर्याप्त हैं) बदलें या बी। संभावित ब्रेकिंग प्रभाव को कम करने के लिए इसे पहले संशोधित करें)।

_{दूसरे शब्दों में, मान लें कि url और data-uri को शुरू में विनिमेय के रूप में डिजाइन किया गया था (यानी data-uri केवल url एक विशेष संस्करण है (और CSS url लिए संकलित है) ulr "इस तरह" (उस तरह के विकल्पों के साथ) क्यों व्यवहार करता है जबकि data-uri "उस तरह" व्यवहार करता है (के साथ) इस तरह के विकल्प), और कुछ व्यवहार प्राप्त करने के लिए आपको data-uri(url()) कॉम्बो की आवश्यकता होगी, एक मिश्रण के अंदर " data-uri तक सीमित और url _out_ इसके साथ --relative-urls: on " <- भृ्रर... :)}

मेरे लिए यह एक फिक्स के बजाय वर्कअराउंड की तरह दिखता है। आगे पुनरावृत्ति पर वे यूआरएल को मिक्सिन में ले जाकर वर्बोसिटी से बचने की कोशिश करेंगे और समस्या फिर से आती है।

हाँ मै सह्मत हूँ।

मैं धीरे-धीरे एक v3 रिलीज के लिए कुछ और प्रयास कम करने के लिए निर्माण करने की कोशिश कर रहा हूं और इसे ठीक कर रहा हूं।

मैं सभी संभावित फ़ाइल पथों पर काम करने और उन्हें एक-एक करके आज़माने के बारे में सोच रहा था - हालांकि यह थोड़ा बुरा है अगर अलग-अलग स्थानों पर कई फाइलें हैं ... मुझे लगता है कि मैं मानता हूं कि इसे हमेशा के लिए पूरी तरह से ठीक करना संभव नहीं है, लेकिन कम से कम हम सामान्य मामले को ठीक कर सकते हैं।

संभावित रूप से एक resolve() फ़ंक्शन हल किए गए यूआरएल को कार्यों में पास करने में मदद कर सकता है (लेकिन फिर यदि यह एक पूर्ण पथ नहीं है जो काम नहीं करेगा और यह तय होने पर एक पूर्ण पथ काम करेगा ...)

क्षमा करें, बस जल्दी से विचार लिख रहे हैं।

यह सिर्फ एक त्वरित टिप्पणी है, लेकिन हमें परिवर्तनीय इंटरपोलेशन का उपयोग करके आयात के साथ बहुत ही समस्या होगी।

परिवर्तनीय इंटरपोलेशन का उपयोग करके आयात करें।

यह दिलचस्प और परेशान करने वाला दोनों है।
क्या यह वास्तव में समर्थित उपयोग-मामला या सुखद संयोग है?

@rjgotten यह समर्थित है, हालांकि समर्थन कुछ हद तक सीमित है। इसे #410 . में ट्रैक किया गया था

यह सही है:

<strong i="8">@variable</strong>: "path.less";
<strong i="9">@import</strong> "@{variable}";

यह नहीं करता:

.mixin(@variable) {
  <strong i="13">@import</strong> "@{variable}";
}

संपादित करें: लिंक काम करने के लिए संशोधित।

मुझे यकीन नहीं है कि मैं मिश्रण में चर @import का समर्थन करना चाहता हूं।
संपूर्ण परिवर्तनीय आयात चीज़ थोड़ा जादू है और कुछ काउंटर-सहज ज्ञान युक्त कोड बना सकती है .. इसलिए मैं इसे हतोत्साहित करना चाहता हूं।

वर्कअराउंड के बारे में बहुत सारी चर्चा, शायद वास्तविक समस्या को ठीक करें? क्या यह स्पष्ट नहीं है कि डेटा-यूरी संसाधित होने वाली फ़ाइल के सापेक्ष होना चाहिए।

अभी मेरे पास फ़ाइल है जो किसी अन्य पथ से _a संदर्भ_ आयात करती है, और यह अभी भी डेटा-यूरी के बारे में शिकायत करती है। कम से कम यह एक बग होना चाहिए? मेरा मतलब है कि अगर मैं संदर्भ द्वारा आयात करता हूं तो उसे वर्तमान फ़ाइल के सापेक्ष पथ को फिर से लिखने का प्रयास नहीं करना चाहिए।

@Ciantic

मेरा मतलब है कि अगर मैं संदर्भ द्वारा आयात करता हूं तो उसे वर्तमान फ़ाइल के सापेक्ष पथ को फिर से लिखने का प्रयास नहीं करना चाहिए।

वास्तव में किस पर आधारित है? इसका reference क्या लेना-देना है?

अभी मेरे पास फ़ाइल है जो किसी अन्य पथ से संदर्भ आयात करती है, और यह अभी भी डेटा-यूरी के बारे में शिकायत करती है।

यह ऊपर के मुद्दे के विपरीत लगता है। क्या आप अधिक विवरण प्रदान कर सकते हैं? (उदाहरण के लिए आयात, आयातित और डेटा फ़ाइलों आदि के पथ)।

शैलियाँ.विहीन

.something {
    background: data-uri("some.svg");
}

सब/टेस्ट.लेस

<strong i="11">@import</strong> (reference) "../style.less";
.test {
    color: green;
}

यह style.less संकलित करता है, लेकिन test.less नहीं क्योंकि यह test.less के सापेक्ष डेटा-यूरी का उपयोग करने का प्रयास करता है।

संदर्भ आयात पथों को फिर से लिखने का प्रयास क्यों करेगा, मेरी राय में संदर्भों का उपयोग करते समय यह आवश्यक नहीं है।

मैं डेटा-यूरी से विकल्पों में यूआरएल पुनर्लेखन नियमों का पालन करने की अपेक्षा करता हूं। बेशक .... यह कहना मुश्किल है कि वास्तव में डेटा-यूरी के साथ इसका क्या अर्थ है।

सामान्य तौर पर, डेटा-यूरी को "कॉलिंग .less फ़ाइल" के सापेक्ष हल करना चाहिए। तो एक मिश्रण के मामले में, जहां मिश्रण कहा जाता है, उसके सापेक्ष इसे हल करना चाहिए, न कि मिश्रण स्थान के सापेक्ष। मिश्रण उन बयानों में "मिश्रित" होता है और फिर उन्हें हल करता है। तो @lukeapage मुझे लगता है कि आपकी व्याख्या सही है:

// app/content/button.less
button {
  .background("images/btn.jpg");
}

इसे app/content/images/ पर btn.jpg खोजना चाहिए। यदि ऐसा नहीं है, तो यह एक बग है क्योंकि ऐसा नहीं है कि मिश्रण कैसे काम करना चाहिए। मुझे नहीं लगता कि यह एक "ब्रेकिंग चेंज" है लेकिन एक बग फिक्स है।

उस ने कहा... मुझे नहीं लगता कि इस तरह के समाधान के साथ कोई समस्या होगी:

1. फोन करने वाले के संबंध में समाधान का प्रयास किया जा रहा है।
2. मिश्रण के सापेक्ष हल करने का प्रयास।

Node.js समाधान के लिए अनेक पथों का प्रयास करता है। जब तक समाधान आदेश स्पष्ट रूप से प्रलेखित है, तब तक आप अपेक्षाओं का प्रबंधन कर सकते हैं। और ऐसा करने का मतलब यह होगा कि अगर किसी ने अपना .less to do व्यवहार # 2 पर आधारित किया होता, तो यह अभी भी लगभग सभी में काम करेगा, यदि सभी मामलों में नहीं।

@ मैथ्यू-डीन
सामान्य तौर पर, डेटा-यूरी को "कॉलिंग .less फ़ाइल" के सापेक्ष हल करना चाहिए। तो एक मिश्रण के मामले में, जहां मिश्रण कहा जाता है, उसके सापेक्ष इसे हल करना चाहिए, न कि मिश्रण स्थान के सापेक्ष। मिश्रण उन बयानों में "मिश्रित" होता है और फिर उन्हें हल करता है।

आप उस काम को कभी भी इस तरह से नहीं कर सकते जो आम तौर पर सभी उपयोग-मामलों के लिए सही हो।

उदाहरण के लिए आप पैरामीट्रिज्ड यूआरएल, यानी प्रतिस्थापन टोकन वाले यूआरएल का समर्थन कैसे करेंगे, जिसे कुछ ज्ञात बेस फ़ोल्डर के खिलाफ हल किया जाना चाहिए, केवल प्रतिस्थापन टोकन भरे हुए हैं? उस मामले को कॉल करने वाले की फ़ाइल के विरुद्ध पुन: व्यवस्थित करने की आवश्यकता है, न कि कॉलर की फ़ाइल।

कॉल साइट पर url() स्पष्ट उपयोग के बिना इसे पारदर्शी रूप से ठीक करने के बारे में मेरे पास एक एपिफेनी थी, जिसे @ सात-चरण-अधिकतम ने एक बुरा विचार कहा था (क्योंकि कोई अंततः _will_ कोशिश करता है इसे मिक्सिन कॉल में रिफ्लेक्टर करें और चीजों को तोड़ें):

जब शाब्दिक Quoted नोड्स बनाए जाते हैं, तो उनकी फ़ाइल जानकारी बनाए रखें। वैरिएबल असाइनमेंट, मिक्सिन कॉल आदि के माध्यम से उस जानकारी का प्रचार करें। कॉलर फ़ाइल से उत्पन्न कोई भी Quoted मूल्य, जब url() या data-uri() द्वारा इलाज किया जाता है, तो उस कॉलर फ़ाइल के विरुद्ध हल किया जाएगा। . लेकिन एक Quoted मान जो किसी मिक्सिन के कुछ आंतरिक तर्क का हिस्सा है, अभी भी मिक्सिन की स्थानीय फ़ाइल के विरुद्ध हल हो जाता है।

यह सब कुछ अपेक्षित रूप से काम करता रहता है, परिदृश्य के लिए प्रतिस्थापन स्ट्रिंग्स के साथ सहेजें जैसे कि:

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

एक चाल है जिसे आप उन्हें ठीक करने के लिए भी खींच सकते हैं: प्रतिस्थापन टोकन भरते समय, यदि कोई टोकन प्रतिस्थापन स्ट्रिंग की शुरुआत में है, तो परिणामी स्ट्रिंग को फ़ाइल जानकारी को टोकन में भरे हुए से प्राप्त करना चाहिए, इसके बजाय प्रतिस्थापन स्ट्रिंग के।

यदि मिक्सिन के अपने लेखक का इरादा इस तरह के पथों को मिक्सिन फ़ाइल के विरुद्ध हल करना है, तो वे अभी भी उस काम को एक पैटर्न के रूप में "./@{image}.jpg" का उपयोग करके कर सकते हैं। यह प्रभावी रूप से जिम्मेदारी के बोझ को कॉलर से दूर कर देता है, जो कि आप चाहते हैं।

// _mixins.less
.sprite(@image) {
    background: data-uri("../images/sprites/@{image}.png") no-repeat;
}

// main.less
div {
   .sprite('logo');
}

आउटपुट:

div {
   background: url(data:image/png;base64,...) no-repeat;
}

वाह, यह बहुत पुराना है... मेरे दो सेंट क्योंकि यह मुद्दा मुझे भी प्रभावित कर रहा है।

यूआरएल फ़ंक्शन में विकल्प जोड़ने या एक नया फ़ंक्शन बनाने के बारे में क्या है, जो यूआरएल को पूर्ण रूप से हल करेगा। इस तरह से कोई फर्क नहीं पड़ता कि मिश्रण कहाँ सेट है, यह पूर्ण पथ के साथ काम करेगा और गलतियों के लिए कोई जगह नहीं होगी।

यूआरएल फ़ंक्शन में विकल्प जोड़ने या एक नया फ़ंक्शन बनाने के बारे में क्या है, जो यूआरएल को पूर्ण रूप से हल करेगा। इस तरह से कोई फर्क नहीं पड़ता कि मिश्रण कहाँ सेट है, यह पूर्ण पथ के साथ काम करेगा और गलतियों के लिए कोई जगह नहीं होगी।

यहां मुद्दा पूर्ण बनाम सापेक्ष पथ के बारे में नहीं था। यह कॉल साइट के खिलाफ रिश्तेदार बनाम घोषणा स्थल के खिलाफ रिश्तेदार के बारे में था। बिल्कुल अलग समस्या।

शायद यह मुद्दा विकसित हो गया है, लेकिन प्रारंभिक टिप्पणी और शीर्षक डेटा-यूरी के बारे में है जो उस फ़ाइल के संबंध में पथ को हल कर रहा है जहां इसे कहा जा रहा था, जो कि कहीं और रखे गए मिश्रण के साथ संयुक्त रूप से पथ को गलत तरीके से हल कर सकता है। खैर, यही वह समस्या है जिसका मैं अनुभव कर रहा हूं।

तो समाधान के रूप में उसमें पूर्ण पथ कारक कहां हैं?

मान लें कि डेटा-यूरी पूर्ण पथ स्वीकार करता है और एक हिपोटेथिकल absolute-url फ़ंक्शन है, निम्न कोड काम करेगा चाहे मिश्रण कहीं भी रखा जाए।

// mixins.less
.background(@image) {
    background-image: data-uri(@image);
}

// app/content/button.less
button {
  .background(absolute-url("images/btn.jpg"));
}

@ miljan-aleksic "पूर्ण" से क्या आपका मतलब data-uri के स्थान पर फ़ाइल के सापेक्ष है? यदि ऐसा है तो "पूर्ण" शायद गलत शब्द है।

ऐसा लगता है कि किसी यूआरएल फ़ाइल-सापेक्ष बनाने के लिए यूआरएल के लिए एक कार्यात्मक रैपर की तरह एक अच्छा तरीका है। या url() के लिए एक अतिरिक्त तर्क।

@ मैथ्यू-डीन, पूर्ण रूप से मेरा मतलब फ़ाइल के लिए पूर्ण पथ है, उदाहरण के लिए: /users/myuser/projects/lessproject/icon.svg ।

मुझे आपका दृष्टिकोण नहीं मिलता है क्योंकि मैं नहीं देखता कि कैसे url() डेटा-यूरी स्थान फ़ाइल के सापेक्ष पथ बना सकता है बिना इसे जाने।

ऐसा लगता है कि किसी यूआरएल फ़ाइल-सापेक्ष बनाने के लिए यूआरएल के लिए एक कार्यात्मक रैपर की तरह एक अच्छा तरीका है। या url() के लिए एक अतिरिक्त तर्क।

मज़े - मज़ें में बहुत; लगभग यही मैंने कुछ साल पहले सुझाया था। ;-)

निरपेक्ष से मेरा मतलब फ़ाइल के लिए पूर्ण पथ से है, जैसे: /users/myuser/projects/lessproject/icon.svg।

ऐसा लगता है कि पूर्ण रूप से आपका मतलब है कि यह absolute-url फ़ंक्शन _pre-resolves_ फ़ाइल के स्थान के आधार पर पूर्ण आउटपुट पथ में इसे पास किया गया सापेक्ष पथ जिसमें absolute-url फ़ंक्शन कहा जाता है, उस स्थान के सापेक्ष जहां संकलित आउटपुट CSS फ़ाइल जाएगी।

यानी आप दोनों का मतलब एक ही है। जैसा कि मैंने उस समय किया था।

यह उस फ़ाइल के स्थान के आधार पर एक पूर्ण आउटपुट पथ पर है जिसमें निरपेक्ष-यूआरएल फ़ंक्शन कहा जाता है, उस स्थान के सापेक्ष जहां संकलित आउटपुट सीएसएस फ़ाइल जाएगी।

जैसा कि, URL या रूटपाथ को फिर से लिखना अभी भी लागू होगा, लेकिन परिभाषा स्थान के आधार पर? यह @lukeapage के मूल उदाहरण से थोड़ा अलग लगता है, जो आउटपुट के सापेक्ष URL के बारे में बात नहीं कर रहा था, लेकिन URL _during compile_; उदाहरण के लिए data-uri() स्थान।

इसलिए इस मुद्दे को ट्रैक करना थोड़ा कठिन है क्योंकि लोगों ने समान मुद्दों के बारे में पोस्ट किया है, लेकिन बिल्कुल समान मुद्दों पर नहीं। यानी, किसी रिश्तेदार _source_ को बदलने के लिए शायद रिश्तेदार _output_ को बदलने की तुलना में बहुत अलग समाधान की आवश्यकता होगी। या शायद नहीं; यह पथिक तर्क पर निर्भर करता है; लेकिन हमें स्पष्ट होना चाहिए कि डेटा-यूरी आउटपुट के रूप में कोई पथ नहीं बनाता है।

शायद हमें resolve() जैसा कुछ चाहिए? मुझे पता नहीं, सिर्फ स्पिटबॉलिंग, लेकिन url(resolve(file(), "my/path")) ? मुझे लगता है कि @ miljan-aleksic का मतलब absolute() , जिसमें यह एक पूर्ण यूआरएल का समाधान करेगा। लेकिन इसे अभी भी एक इनपुट लेना चाहिए (जैसे file() , इसके खिलाफ हल करने के लिए)। अन्यथा आप उस तर्क को एक फ़ंक्शन में निर्दिष्ट करने के लिए file-resolve() जैसा कुछ कर सकते हैं, लेकिन resolve() और file() रूप में दो फ़ंक्शन अलग-अलग उपयोगी हो सकते हैं।

इस सब के बारे में मुश्किल हिस्सा सभी पुनर्लेखन यूआरएल विकल्प हैं, जिनमें से पीआर मर्ज के रूप में अब और अधिक मॉड्यूल समर्थन जोड़ा गया है। (https://github.com/less/less.js/pull/3248)। तो अगर यह एक फ़ाइल-सापेक्ष यूआरएल देता है, तो क्या इसे अभी भी फिर से लिखा जा सकता है? मैं हां मानूंगा, लेकिन हमें स्पष्ट होना होगा।

हां, संकल्प() और फ़ाइल() ठीक वही परिभाषित करता है जो मैं समझाने की कोशिश कर रहा था। मुझे उम्मीद है कि हम इसे निकट भविष्य में लागू होते देख सकते हैं।

@ miljan-aleksic ठीक है, यह तब समझ में आता है।

असल में, file() बिल्कुल सही नहीं है, क्योंकि यह फ़ाइल नाम लौटाएगा जो मुझे लगता है, यह dir() जैसा होगा। और यह शायद प्रति फ़ाइल एक चर स्थिरांक होना चाहिए।

व्हाट अबाउट:

data-uri(resolve(<strong i="10">@DIR</strong>, "my/path"))

तो, दो चीजें जोड़ी गईं: 1) पथों को संयोजित करने के लिए एक संकल्प () फ़ंक्शन, 2) एक @DIR (और @FILE ?) मूल्यांकन करते समय प्रत्येक फ़ाइल में निरंतर इंजेक्ट किया जाता है। इसके बारे में एकमात्र मुश्किल बात यह होगी कि इंजेक्शन वाले वर्र्स ओवरराइड नहीं करते हैं या रूट में अन्य वर्र्स के साथ विलय नहीं होते हैं, लेकिन इसके खिलाफ परीक्षण करना काफी आसान होना चाहिए। या उन्हें लोअरकेस होना चाहिए, जैसे @arguments ? इस मामले में, मैं संघर्षों से बचने के लिए @directory और @filename का सुझाव दूंगा। सबसे कम-वाई विकल्प क्या है?

शायद हमें resolve() जैसा कुछ चाहिए?

^ बिंगो। ठीक है कि।

सबसे कम-वाई विकल्प क्या है?

मैं Node.js-y विकल्प के लिए जाऊंगा: __dirname
यह लंबे समय से आसपास रहा है और प्रसिद्ध है। कम में समान अवधारणा के लिए समान नाम का उपयोग करना एक अच्छा विचार हो सकता है।

मैं Node.js-y विकल्प के लिए जाऊंगा: __dirname

एर... जो कम/सीएसएस कीवर्ड से मेल नहीं खाएगा और न ही कम परिवर्तनीय और न ही फ़ंक्शन सेमेन्टिक्स। हमें इससे बेहतर करना होगा। @__dirname हो सकता है, लेकिन अंडरस्कोर अभी भी भाषा के लिए थोड़ा अजीब है। यह बिल्कुल भी फिट नहीं है।

अंडरस्कोर अभी भी भाषा के लिए थोड़ा अजीब है। यह बिल्कुल भी फिट नहीं है।

एक डबल लीडिंग अंडरस्कोर का उपयोग कई भाषाओं में 'सिस्टम द्वारा प्रदान की जाने वाली कुछ' को इंगित करने के लिए किया जाता है, खासकर जब आंतरिक चर जैसी चीजों की बात आती है। तो आउट-ऑफ़-प्लेसनेस वहाँ एक तरह का बिंदु है।

बेशक; अगर आपको यह पसंद नहीं है, तो आप हमेशा @dirname या @dir-name जैसे व्युत्पन्न के साथ जा सकते हैं।

हालाँकि, इस बारे में कुछ और सोचने के बाद, हम वर्तमान फ़ाइल पथ को एक चर के रूप में _need_ क्यों उजागर करते हैं? क्या इसे वैचारिक resolve() फ़ंक्शन में ही नहीं बुना जा सकता है?

क्या इसे वैचारिक संकल्प () फ़ंक्शन में ही नहीं बुना जा सकता है?

और हम अपने प्रस्ताव पर वापस आ गए, बस एक अलग फ़ंक्शन नाम के साथ। मैं अभी भी इसे सबसे ज्यादा पसंद करता हूं, संकल्प के रूप में भी बेहतर ()।

और हम अपने प्रस्ताव पर वापस आ गए, बस एक अलग फ़ंक्शन नाम के साथ।

की तरह।

मुझे जो मिल रहा है वह यह है कि कॉल को resolve() फ़ंक्शन पर रखने वाली फ़ाइल के यूआरएल/पथ में पास करने की आवश्यकता नहीं है, क्योंकि वह स्थान फ़ंक्शन के लिए _ज्ञात_ होना चाहिए।

किसी फ़ंक्शन के अंदर this एक FunctionCaller उदाहरण को संदर्भित करता है, जिसमें currentFileInfo संपत्ति होती है।
उस गुण को फ़ंक्शन कॉल के अनुरूप Call AST नोड की फ़ाइल जानकारी में प्रारंभ किया जाता है।
अर्थात

https://github.com/less/less.js/blob/4e903e8254cc20fec80fccd35794fb797949e653/lib/less/tree/call.js#L47

अगर मैं कोड को सही ढंग से पढ़ रहा हूं, तो वहां फ़ाइल जानकारी उस स्थान की फ़ाइल जानकारी से मेल खाती है जहां फ़ंक्शन कॉल _declared_ है - वह फ़ाइल नहीं जहां फ़ंक्शन कॉल का मूल्यांकन किया जाता है।

इसका मतलब है कि इस फ़ाइल जानकारी का उपयोग 'उत्सुक' यूआरएल रिज़ॉल्वर के लिए करना ठीक होना चाहिए। यह अपेक्षित रूप से कार्य करेगा, भले ही एक फ़ंक्शन कॉल को किसी मिक्सिन के अंदर रखा गया हो जिसे किसी अन्य फ़ाइल के संदर्भ में आयात और मूल्यांकन किया गया हो। अर्थात्: उस फ़ाइल पर पिन किए गए रिज़ॉल्यूशन के साथ जहां मिक्सिन को परिभाषित किया गया है।

हालाँकि, इस बारे में कुछ और सोचने के बाद, हमें वर्तमान फ़ाइल पथ को एक चर के रूप में उजागर करने की आवश्यकता क्यों है? क्या इसे वैचारिक संकल्प () फ़ंक्शन में ही नहीं बुना जा सकता है?

अगर हमें यकीन है कि किसी को भी वर्तमान फ़ाइल या सामान्य रिज़ॉल्वर फ़ंक्शन की आवश्यकता नहीं है ... हो सकता है ... बात एक स्पष्ट स्थानीय संस्करण है, यह स्पष्ट करता है कि यह एक सामान्य कार्य नहीं है, और यह कि फ़ंक्शन का मूल्यांकन नहीं किया जाएगा जैसे कोई अन्य समारोह। यही मेरी असली चिंता है, शब्दार्थ है। कोई फर्क नहीं पड़ता कि आप इसे क्या नाम देते हैं, यदि आपके पास "वर्तमान फ़ाइल" के लिए एक विशेष "मार्कर" नहीं है, तो यह किसी अन्य फ़ंक्शन की तरह नहीं है जो इनपुट के आधार पर इसे हल करता है। दूसरे शब्दों में, यह एक ऐसा कार्य है जो अदृश्य इनपुट के अनुसार हल होता है, और यह मुझे चिंतित करता है। हालांकि, अगर फ़ंक्शन current-file-resolve() तरह बेहद स्पष्ट है, तो शायद यह पर्याप्त स्पष्ट है। अन्यथा आप केवल लोगों को भ्रमित करने जा रहे हैं कि एक मिक्सिन कॉल ने specialfunction() को उस फ़ाइल के अनुसार हल क्यों नहीं किया, जिसमें फ़ाइल को मिक्सिन को परिभाषित किया गया था।

तो, नहीं, एक स्थानीय संस्करण तकनीकी रूप से _needed_ नहीं है, लेकिन अर्थ/आउटपुट/व्यवहार को शब्दार्थ से स्पष्ट होना चाहिए।

हम्म...

ठीक है। फिर हमारे पास resolve-url(url, [base]) फ़ंक्शन है - एक वैकल्पिक base ; फ़ाइल की निर्देशिका में डिफ़ॉल्ट रूप से जिसमें फ़ंक्शन कॉल लिखा/घोषित/परिभाषित किया गया है। फिर एक declared-dir() फ़ंक्शन है जो सिर्फ this.fileInfo खींचता है और पथ को पकड़ लेता है, क्या लेखक स्पष्ट रूप से पथ खींचना चाहते हैं; किसी भिन्न फ़ाइल से पथ लेना चाहते हैं; या इसे किसी अन्य विशेषता के भाग के रूप में उपयोग करने की आवश्यकता है जो URL रिज़ॉल्यूशन से संबंधित नहीं है।

यानी एक फुल फॉर्म कॉल (बिना निहित आधार के) कुछ ऐसा होगा:

resolve-url("../foo", declared-dir())

... और सिर्फ करने के बराबर होगा

resolve-url("../foo")

... जो आलसी के बराबर उत्सुक है

url("../foo")

उस तरह से 'स्वचालित रूप से' इंजेक्शन वाले चर की आवश्यकता नहीं है। यह पूरी तरह से प्लगइन कार्यों के एक सेट के रूप में लागू किया जा सकता है, मुझे लगता है। और हमें जिस एकमात्र कोर मैकेनिक की आवश्यकता है, वह है यूआरएल को 'पहले से ही हल' के रूप में चिह्नित करने का एक तरीका, ताकि डिफ़ॉल्ट रिज़ॉल्वर लॉजिक को resolve-url फ़ंक्शन से बाहर आने वाले URL पर चलने से रोका जा सके।

पाठ्यक्रम के दस्तावेज़ीकरण में शब्दार्थ को स्पष्ट किया जाना चाहिए। और वह प्रलेखन स्पष्ट रूप से तुलना कर सकते हैं url के खिलाफ resolve-url उत्सुक और आलसी मूल्यांकन / संकल्प वर्णन करने के लिए।

_{बस अगर "इंजेक्शन वैरिएबल" विचार काम नहीं करेगा (w/o अतिरिक्त हैक्स) वैसे भी क्योंकि आयातित फाइलों का एक ही दायरा होता है।}

<strong i="7">@__dir</strong>: "whatever";
// *everywhere* it's the only <strong i="8">@__dir</strong> value = the path of "c"
<strong i="9">@import</strong> "a";
<strong i="10">@import</strong> "b";
<strong i="11">@import</strong> "c";

फ़ंक्शन-आधारित कार्यान्वयन के बारे में बोलते हुए, मुझे लगता है (लेकिन सुनिश्चित नहीं हो सकता) कि फ़ाइल का पथ प्राप्त करना अभी भी संभव है जहां फ़ंक्शन को this.context.? या this.context.frames[?] में कहीं भी बुलाया गया है। या ऐसा।

एम्म्म, तो हमारे पास इसे हल करने का कोई बेहतर तरीका नहीं है?

@ हेनेक्स्ट
एम्म्म, तो हमारे पास इसे हल करने का कोई बेहतर तरीका नहीं है?

आलसी मूल्यांकन इसे ठीक से हल करना बहुत कठिन बनाता है, मुझे डर है।

@ सात-चरण-अधिकतम
फ़ंक्शन-आधारित कार्यान्वयन के बारे में बोलते हुए, मुझे लगता है (लेकिन सुनिश्चित नहीं हो सकता) कि फ़ाइल का पथ प्राप्त करना अभी भी संभव है जहां फ़ंक्शन को इसके this.context.? या this.context.frames[?] में कहीं भी बुलाया गया है। या ऐसा।

आपको इसके पदानुक्रम में Call नोड खोजने में सक्षम होना चाहिए, हाँ।