Fable: स्रोत मानचित्र समर्थन वापस लाएं

क्या Fable 3 को अब fable-compiler पैकेज के माध्यम से वितरित नहीं किया जाएगा ( fable-loader साथ प्रयोग किया जाता है)? 😱 मैं समझता हूं कि नोड.जेएस ऐप बनाने के लिए फ़ेबल-स्प्लिटर की तुलना में शुद्ध फ़ेबल ऐप में बेहतर उपयोगकर्ता अनुभव है, लेकिन एनपीएम वितरण को हटाने से हर जगह बहुत बड़ा बदलाव होगा और ईमानदारी से काम करने के लिए पीठ में थोड़ा दर्द होगा: टेम्प्लेट, लाइब्रेरी और परियोजनाओं। यह कहना बहुत आसान है: npm upgrade fable-compiler और यह जाने के लिए तैयार हो जाएगा (उम्मीद है कि परिवर्तनों को तोड़े बिना)

चूंकि उन्होंने स्थानीय उपकरणों के संस्करण-पिनिंग को तय किया है, इसलिए Fable 3 को एक डॉटनेट टूल के रूप में वितरित करने का रास्ता संभव है, जैसा कि अन्य सभी F # टूल कर रहे हैं (Paket, Fake, Fantomas, Femto, Snowflaqe)। फ़ेबल-कंपाइलर को समानांतर वितरण के रूप में रखना उपयोगकर्ताओं के लिए स्पष्ट कट होने की तुलना में अधिक भ्रमित करने वाला होगा।

मैं पसंद करूंगा यदि लोगों को Fable को डॉटनेट टूल के रूप में कॉल करने की आदत हो लेकिन... मैं समझता हूं कि सभी ट्यूटोरियल्स, प्रोजेक्ट्स, टेम्प्लेट्स को अपडेट करना एक दर्द है (जैसा कि यह अतीत में रहा है)। इसलिए हम एक नया फैबल-लोडर प्रमुख संस्करण जारी करने पर विचार कर सकते हैं जो सिर्फ फैबल डॉटनेट टूल को आमंत्रित करता है। अपग्रेड करने के चरण (जब स्थिर संस्करण रिलीज़ होते हैं) तब बस होंगे:

dotnet tool install fable
npm upgrade fable-loader

संभवतः *.fs.js को .gitignore में भी जोड़ रहे हैं। fable-compiler को अनइंस्टॉल किया जा सकता है या नहीं, इसे अभी लागू नहीं किया जाएगा। यह कैसा दिखेगा? और, क्या कोई स्वेच्छा से नए कल्पित-लोडर को बनाए रखेगा? मैं

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

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

मुझे फैबल-स्प्लिटर का उपयोग करने के बजाय नोड.जेएस अनुप्रयोगों के निर्माण और चलाने को सरल बनाने के लिए सीएलआई उपकरण पसंद है

चूंकि उन्होंने स्थानीय उपकरणों के संस्करण-पिनिंग को ठीक कर दिया है, इसलिए Fable 3 को एक डॉटनेट टूल के रूप में वितरित करने की संभावना है

हो सकता है कि मौजूदा उपयोगकर्ताओं से यह पूछने के लिए कि वे क्या पसंद करेंगे?

चर्चा को #2195 पर ले जाना क्योंकि यह मुद्दा स्रोत मानचित्रों के बारे में है और यह योगदानकर्ताओं के लिए भ्रमित करने वाला हो सकता है।

स्रोत मानचित्रों के बिना VSCode में launch.json माध्यम से चरण-दर-चरण डिबगिंग के साथ एकीकृत करने का कोई तरीका नहीं होगा, क्या यह सही है?

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

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

मैंने अभी तक इस पर कोई कोड शुरू नहीं किया है लेकिन मैं इस पर नजर रख रहा हूं। मेरा पहला झुकाव मोज़िला/स्रोत-मानचित्र का सीधा बंदरगाह है, यह मानते हुए कि यह वही है जो जरूरी है लेकिन फिर मैं सोच रहा हूं कि बंदरगाह के लिए सी # या एफ # के साथ जाना बेहतर होगा, मैं पसंद करूंगा इसे स्वयं F# में लिखें लेकिन C# चुनने में कुछ लाभ हैं। किसी भी तरह से पुस्तकालय को पोर्ट करना सामान्य रूप से स्रोत-मानचित्रों के साथ काम करने के लिए एक मूल .NET कार्यान्वयन प्रदान करेगा जो कि .NET पारिस्थितिकी तंत्र के लिए एक उपयोगी चीज हो सकती है। अभी के लिए मैंने इस विकल्प को अपने सीमित खाली समय में एक शॉट देने के इरादे से इस परियोजना को

एक अन्य विकल्प शायद जो अभी मेरे साथ हुआ है, वह होगा WebAssembly को संकलित करने के लिए Mozilla/source-map लाइब्रेरी के लिए WebAssembly समर्थन का उपयोग करना और फिर WASM को .NET लाइब्रेरी में Wasmtime का उपयोग करके एम्बेड करना । मैं इस विकल्प से उतना परिचित नहीं हूं, लेकिन अगर यह काम करता है और यथोचित प्रदर्शन करता है तो यह कार्यान्वयन को जावास्क्रिप्ट में मूल स्रोत-मानचित्र पुस्तकालय के साथ समन्वयित रखने का एक आसान तरीका हो सकता है।

एक अन्य विकल्प शायद जो अभी मेरे साथ हुआ है, वह होगा WebAssembly को संकलित करने के लिए Mozilla/source-map लाइब्रेरी के लिए WebAssembly समर्थन का उपयोग करना और फिर WASM को .NET लाइब्रेरी में Wasmtime का उपयोग करके एम्बेड करना । मैं इस विकल्प से उतना परिचित नहीं हूं, लेकिन अगर यह काम करता है और यथोचित प्रदर्शन करता है तो यह कार्यान्वयन को जावास्क्रिप्ट में मूल स्रोत-मानचित्र पुस्तकालय के साथ समन्वयित रखने का एक आसान तरीका हो सकता है।

लगभग ऐसा लगता है कि हमें F# ट्रांसपिलर के लिए जावा-स्क्रिप्ट की आवश्यकता है...

पूरी गंभीरता से, एक एफ # स्रोत मानचित्र पुस्तकालय एक अच्छा विचार होगा।

https://github.com/delneg/source-map-sharp
https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js का अनुवाद करते हुए कुछ काम शुरू किया
वहां, सबसे अच्छा कोड बिल्कुल नहीं, लेकिन मैंने सीधा अनुवाद करने की कोशिश की

यह बहुत अच्छा है @delneg , बहुत बहुत धन्यवाद! मुझे लगता है कि एक सीधा अनुवाद सबसे अच्छा काम करता है, भले ही वह एफ # मुहावरेदार न हो, अगर हमें बाद में मूल पुस्तकालय के अपडेट को सिंक करने की आवश्यकता होती है: +1:

मैंने कुछ काम किया है (यहां https://github.com/delneg/source-map-sharp), लेकिन मुझे "util.js" फ़ंक्शन जैसे util.join , util.relative मदद की आवश्यकता हो सकती है source-map-generator.js

मुझे लगभग यकीन है कि हमें F# प्रकार की सुरक्षा के कारण util.getArg आवश्यकता नहीं होगी, और मुझे पूरा यकीन है कि हमें util.toSetString आवश्यकता नहीं होगी क्योंकि यह '__proto__' से संबंधित बग से बचने के लिए एक हैक है।

कृपया मुझे यह भी बताएं कि क्या हम इसका उपयोग सीएलआई के रूप में करेंगे या ...?

धन्यवाद @ डेलनेग! मैं सप्ताहांत में देखूंगा और मैं उन कार्यों को पीआर करने की कोशिश करूंगा: +1: हां, पुस्तकालय का उपयोग Fable.Cli से किया जाएगा। यदि आप इसे एक स्वतंत्र पुस्तकालय के रूप में प्रकाशित करते हैं तो हम केवल आपके Nuget पैकेज का संदर्भ दे सकते हैं।

मैंने अधिकांश SourceMapNode, SourceMapGenerator किए हैं, और वर्तमान प्रगति को प्रदर्शित करने के लिए एक README.md बनाया है।
साथ ही, आप पता कर सकते हैं कि किस तरह की मदद की जरूरत है।

यहाँ डॉक्स के अनुसार https://github.com/mozilla/source-map#generating -a-source-map , जो अब हमारे पास है वह स्रोत मानचित्र बनाने के लिए पर्याप्त है ... (बिल्कुल, मुझे पूरी तरह से यकीन नहीं है कि कैसे एटीएम)

यह शानदार है @delneg! मैंने इसे एक त्वरित प्रयास दिया और ऐसा लगता है कि काम कर रहा है: +1: अब मैं डिबगिंग सक्षम करने का प्रयास करूंगा।

यह अच्छा है, क्या आप अगले चरणों का प्रस्ताव दे सकते हैं?
यानी नगेट प्रकाशित करना या परीक्षण लिखना या कुछ और (शायद रेपो में रीडमे से कुछ)
(पीएस हालांकि मैंने कभी नगेट प्रकाशन नहीं किया है, और संभवत: कल्पित खाते का उपयोग करके किया जाना चाहिए)
पीपीएस कोई आश्चर्य नहीं कि इसने तुरंत काम किया, एफ # का उपयोग करते समय मुझे इसकी काफी आदत हो गई है

अगले चरण में परीक्षण किया जाना चाहिए कि सोर्समैप्स वास्तव में डिबगिंग के लिए काम करते हैं और फैबल में अतिरिक्त काम करते हैं ( --sourceMap विकल्प जोड़कर, इसे एक फ़ाइल में सहेजते हैं। मैं इसे अपनी तरफ से कर सकता हूं। मैं आपको एक पीआर भी भेजूंगा एपीआई को थोड़ा पॉलिश करने के लिए (जैसे स्पष्ट विकल्पों के बजाय वैकल्पिक तर्कों का उपयोग करना)।

अभी हमारे पास Fable Nuget खाता नहीं है, हम अपने व्यक्तिगत खाते के साथ पैकेज प्रकाशित कर रहे हैं और आमतौर पर केवल 2-3 मालिकों के मामले में। यदि आप nuget.org में एक खाता बनाते हैं और एक टोकन उत्पन्न करते हैं, तो प्रकाशन को स्वचालित करना आसान है । मैं उसके लिए स्क्रिप्ट का पीआर कर सकता हूं। आप चाहें तो मुझे पैकेज के सहयोगी के रूप में भी जोड़ सकते हैं।

ठीक है, मेरे पास समय होने पर मैं nuget प्रकाशन सामग्री देख लूंगा
साथ ही, मैंने आपको रेपो में सहयोगी के रूप में जोड़ा है
अगर मैं कर पाऊंगा, तो मैं एपीआई को भी थोड़ा पॉलिश करने की कोशिश करूंगा, और SourceGenerator के लिए कुछ परीक्षण जोड़ने का प्रयास करूंगा

मैंने SourceMapGenerator के लिए और परीक्षण जोड़ना शुरू कर दिया है, उन्होंने कुछ बग का खुलासा किया जो छुपा रहे थे।
कुछ अब ठीक हो गए हैं, लेकिन ऐसा लगता है कि उन सभी को ठीक करने की आवश्यकता है - अन्यथा कुछ मामलों में मैपिंग काम नहीं कर सकती है
इसलिए, nuget atm . को प्रकाशित करना थोड़ा जल्दी है
अगर कोई मदद करना चाहता है - असफल परीक्षणों पर एक नज़र डालें ( dotnet test )

https://www.nuget.org/packages/source-map-sharp/
मैंने nuget पैकेज प्रकाशित किया है, SourceMapGenerator संबंधित वास्तविक मैपिंग पीढ़ी (SerializeMapping फ़ंक्शन) के लिए परीक्षण किए गए हैं और बग्स को ठीक किया गया है, इसलिए इसे ठीक से काम करना चाहिए।
मैं SourceNode और अन्य सामग्री पर जारी रखूंगा, और यह बहुत अच्छा होगा यदि some1 util.relative / util.join साथ मदद कर सके

यह बहुत अच्छा है @delneg! इसके लिए बहुत - बहुत धन्यवाद! मैं छुट्टियों के बाद धीरे-धीरे काम पर वापस आ रहा हूं इसलिए जब संभव हो तो मैं आपके पैकेज का उपयोग करके स्रोत मानचित्र समर्थन के साथ एक Fable 3.1 बीटा रिलीज को आगे बढ़ाने की कोशिश करूंगा: +1:

मुझे लगता है कि Fable को स्वयं SourceNode की आवश्यकता नहीं है, लेकिन यदि आप इसे पूर्णता के लिए जोड़ना पसंद करते हैं तो यह पुस्तकालय के अन्य उपभोक्ताओं की मदद कर सकता है। लगभग util.relative/join , मैं आपके प्रोजेक्ट के लिए एक पीआर भेजने की भी कोशिश करूंगा, लेकिन यह देखते हुए कि यह .NET पर चलेगा, मुझे लगता है कि आपको System.IO.Path.GetRelativePath और System.IO.Path.Combine का उपयोग करने में सक्षम होना चाहिए। : https://docs.microsoft.com/en-us/dotnet/api/system.io.path?view=net-5.0

दुर्भाग्य से, GetRelativePath netstandard2.0 के लिए उपलब्ध नहीं है (देखें https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrelativepath?view=net-5.0#applies -प्रति)
समाधान netstandard2.1 से टकराना हो सकता है (मुझे नहीं पता कि यह एक अच्छा है, हालांकि)
util.join - सभी अवसरों को देखने के बाद, मेरा मानना ​​​​है कि इसका उपयोग केवल consumer -संबंधित मामलों में किया जाता है (जो मैं एटीएम नहीं करूँगा), इसलिए वास्तव में इसकी अभी आवश्यकता नहीं है।

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

.Net Standard 2.1 मोनो-संबंधित चीजों को धूल में छोड़ देगा (यानी Xamarin चीजें)। लेकिन Fable उपयोग के मामले के लिए शायद यह ठीक है क्योंकि यह केवल विकास-निर्भरता है और ढांचे का वास्तव में रनटाइम पर कुछ भी मतलब नहीं है।

तो अगर पुस्तकालय केवल Fable में उपयोग किया जा रहा है, 2.1 ठीक है, लेकिन यदि आप अन्य .Net सामग्री के साथ अधिकतम संगतता चाहते हैं, तो 2.0 उसके लिए अधिक आदर्श है।

FWIW, किसी ने StackOverflow पर इसका सरल कार्यान्वयन प्रदान किया: https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

.Net Standard 2.1 मोनो-संबंधित चीजों को धूल में छोड़ देगा (यानी Xamarin चीजें)। लेकिन Fable उपयोग के मामले के लिए शायद यह ठीक है क्योंकि यह केवल विकास-निर्भरता है और ढांचे का वास्तव में रनटाइम पर कुछ भी मतलब नहीं है।

तो अगर पुस्तकालय केवल Fable में उपयोग किया जा रहा है, 2.1 ठीक है, लेकिन यदि आप अन्य .Net सामग्री के साथ अधिकतम संगतता चाहते हैं, तो 2.0 उसके लिए अधिक आदर्श है।

एफडब्ल्यूआईडब्ल्यू, किसी ने स्टैक ओवरफ्लो पर इसका एक सरल कार्यान्वयन प्रदान किया: stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

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

संपादित करें: अपलोड 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 netstandard2.1 के साथ

एक अन्य विकल्प सशर्त रूप से (#if के साथ) उन चीजों को बाहर करना होगा जो मल्टीटार्गेटिंग के माध्यम से GetRelativePath पर निर्भर हैं, ताकि बाकी सब कुछ .Net मानक 2.0 पर उपलब्ध हो।

एक अन्य विकल्प सशर्त रूप से (#if के साथ) उन चीजों को बाहर करना होगा जो मल्टीटार्गेटिंग के माध्यम से GetRelativePath पर निर्भर हैं, ताकि बाकी सब कुछ .Net मानक 2.0 पर उपलब्ध हो।

एक साधारण सापेक्ष यूआरएल की समस्या के लिए एक overcomplication की तरह लगता है (केवल एटीएम जिसके लिए GetRelativePath की आवश्यकता होती है)

डॉटनेट टूल के रूप में फ़ेबल netcoreapp3.1 है, इसलिए netstandard2.1 को लक्षित करना ठीक है, बस आपको विंडोज़ में Path.GetRelativePath(path, pathTo).Replace('\\', '/') जैसे चलने पर पथ को सामान्य करने की आवश्यकता हो सकती है।

यदि आप चाहते हैं कि पुस्तकालय अधिकतम अनुकूलता के लिए netstandard2.0 को लक्षित करे, जैसा कि @jwosty बताता है, तो वास्तव में हमारा अपना कार्यान्वयन है। मैंने इसे थोड़ी देर में छुआ नहीं है, लेकिन यह ठीक काम करता प्रतीत होता है: https://github.com/fable-compiler/Fable/blob/ba509a94a50522794d3e60f27dd826bb5602eca1/src/Fable.Transforms/Global/Prelude.fs#L508 -L555

इसके अलावा Path.GetRelativePath हमेशा सापेक्ष पथ के सामने एक अवधि नहीं जोड़ता है:

> Path.GetRelativePath("/foo/bar", "/foo/bar/hoho/mir");;
val it : string = "hoho\mir"

सोर्समैप्स यूआरएल के लिए शायद अवधि की आवश्यकता है, इसलिए पथ को सामान्य करते समय आपको उपरोक्त अंश के 545-548 की तरह कुछ भी करने की आवश्यकता हो सकती है।

मैं ऊपर दी गई सामग्री की जांच करूंगा और जेएस से परीक्षण अनुकूलित करूंगा (test-util.js में काफी गुच्छा है), शायद हमारे अपने कार्यान्वयन का उपयोग करेगा।
इसके अलावा, कुछ प्रश्न शेष हैं:
1) शायद हमें चर्चा को स्रोत-मानचित्र-तेज भंडार मुद्दों पर माइग्रेट करना चाहिए?
2) क्या हम इस परियोजना के लिए किसी प्रकार के डब्ल्यूएएसएम संकलन का उपयोग करने की योजना बना रहे हैं (क्या ऐसा करने का कोई कारण है, क्योंकि मुझे मूल स्रोत-मानचित्र रेपो एटीएम में डब्ल्यूएएसएम उपयोग का कारण नहीं पता है)?
3) क्या स्रोत-मानचित्र-तेज का उपयोग शुरू करने के लिए फैबल के लिए कुछ और आवश्यक है, अगर कुछ भी (दस्तावेज़, परीक्षण, अतिरिक्त एपीआई आदि सहित)?

संपादित करें: ठीक है, यह आसान था, पहले से ही कस्टम Util.getRelativePath जोड़ा गया, परीक्षण जोड़ा गया और मामूली संशोधन के बाद वे हरे हो गए।
क्या हमें netstandard2.0 पर वापस लौटना चाहिए और/या 1.0.2 nuget प्रकाशित करना चाहिए?

बहुत बढ़िया @delneg! 👏 🚀 👏

1. हां, चर्चा को स्रोत-मानचित्र-तेज भंडार में ले जाना समझ में आता है: +1: जब आपको मेरे इनपुट की आवश्यकता हो तो कृपया मेरा उल्लेख करें ताकि मुझे अधिसूचना मिल सके।
2. मूल स्रोत-मानचित्र में WASM उपयोग की जाँच नहीं की, लेकिन मुझे लगता है कि वे संख्यात्मक गणनाओं को गति देने के लिए WASM का समर्थन करने वाले वातावरण में इसका उपयोग करते हैं। मुझे नहीं लगता कि हमें .NET पोर्ट में इसके बारे में चिंता करने की ज़रूरत है।
3. यह ठीक होना चाहिए, मेरे पास इन दिनों अधिक समय नहीं था, लेकिन मैं स्रोत मानचित्रों के साथ जल्द ही 3.1 बीटा रिलीज़ प्रकाशित करने का प्रयास करूंगा आप आगे बढ़ सकते हैं और 1.0.2 प्रकाशित कर सकते हैं इसलिए हम बीटा में इसका उपयोग करते हैं।

Fable 3.1 बीटा को स्रोत मानचित्र समर्थन के साथ @delneg शानदार कार्य के लिए धन्यवाद के साथ प्रकाशित किया गया है! :टाडा: https://twitter.com/FableCompiler/status/1347421291502997504

शानदार - एक कल्पित उपयोगकर्ता से: इस @delneg के लिए बहुत धन्यवाद!

अदभुत अदभुत अदभुत !

बहुत बढ़िया @delneg! 👏 🚀 👏

1. Yes it makes sense to move discussion to source-map-sharp repository 👍 Please mention me when you need my input so I get the notification.

2. Didn't check WASM usage in original source-map, but I assume they use it in environments supporting WASM to speed up numeric calculations. I don't think we need to worry about it in the .NET port.

3. It should be fine, I just didn't have much time these days, but I'll try to publish a 3.1 beta release soon with source maps 💪 You can go ahead and publish 1.0.2 so we use this in the beta.

आपके समर्थन के लिए धन्यवाद।
मैं भविष्य में स्रोत-मानचित्र-तेज बनाए रखने के लिए अपनी पूरी कोशिश करूंगा, और मुझे खुशी है कि यह अब काम करता है।
1) मैं तब रेपो के मुद्दों में लिखूंगा, और यदि किसी के पास कोई प्रश्न आदि है - कृपया स्रोत-मानचित्र-तेज में एक मुद्दा खोलें
2) हाँ, मुझे लगता है कि उन्होंने प्रदर्शन में सुधार के लिए WASM का उपयोग किया था।
मैंने कोशिश की और स्रोत-मानचित्र-तेज काम का WASM संस्करण प्राप्त किया, हालांकि .net में WASM संकलन की स्थिति भयानक और उपयोग करने में बहुत कठिन लगती है (कुछ काम Uno.Platform.Bootstrap प्रोजेक्ट में किया जाता है, लेकिन इसे देखकर स्रोत कोड ने मुझे बहुत निराश किया)
जहां तक ​​सोर्स-मैप-शार्प को .NET एप्लिकेशन रखा जाता है, अगर हमें कभी भी अधिक परफॉर्मेंस की आवश्यकता होगी तो हम हमेशा स्पैन को देख सकते हैंऔर अन्य .NET सामान इसे तेज़ बनाने के लिए
३) मैंने १.०.२ प्रकाशित किया और मैंने देखा कि आप पहले ही इसका उपयोग कर चुके हैं, तो बस इतना ही।
मैं भविष्य में Nuget के प्रकाशन को जारी रखने की कोशिश करूंगा यदि हमें कोई बग आदि मिले (और एपीआई को बदलने की कोशिश न करें)

@alfonsogarciacaro से निर्देशों को लागू करने के बाद भी स्रोत मानचित्र नहीं देख रहे किसी के लिए, अपनी आउटपुट फ़ाइलों (सभी .fs.js वाले सहित) को साफ़ करने का प्रयास करें और अपना निर्माण फिर से चलाएं। मुझे यह पता लगाने में थोड़ा समय लगा क्योंकि बिना सफाई के बस पुनर्निर्माण से काम नहीं चला।

इसके अलावा, इस शानदार फीचर को वापस लाने के लिए शामिल सभी लोगों को धन्यवाद

अद्भुत कार्य! मैं आज वापस आया यह देखने के लिए कि क्या मैं इस परियोजना को उठा सकता हूं और मेरी खुशी के लिए यह पहले ही पूरा हो चुका है। मैंने उस रेपो को संग्रहीत जिसे मैंने इस प्रयास के लिए https://github.com/delneg/source-map-sharp रेपो की ओर इशारा किया। फिर से बढ़िया काम!