Fable: إعادة دعم خريطة المصدر

تم إنشاؤها على ١٥ سبتمبر ٢٠٢٠  ·  35تعليقات  ·  مصدر: fable-compiler/Fable

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

help wanted

التعليق الأكثر فائدة

https://github.com/delneg/source-map-sharp
بدأت بعض الأعمال في ترجمة https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js
هناك ، ليس أفضل رمز على الإطلاق ولكني حاولت القيام بترجمة مباشرة

ال 35 كومينتر

هل لن يتم توزيع Fable 3 عبر حزمة fable-compiler (تُستخدم بجانب fable-loader )؟ 😱 أتفهم أن تطبيق Fable الخالص يتمتع بتجربة مستخدم أفضل من fable-splitter لإنشاء تطبيقات node.js ولكن إزالة توزيع npm سيكون تغييرًا كبيرًا في كل مكان وبصراحة سيكون هناك القليل من الألم في الخلف للعمل مع: القوالب والمكتبات والمشاريع. من الأسهل جدًا القول: npm upgrade fable-compiler وسيكون جاهزًا للانطلاق (نأمل دون تغيير التغييرات)

نظرًا لأنهم قاموا بإصلاح تثبيت إصدار الأدوات المحلية ، فمن المحتمل أن يكون توزيع Fable 3 كأداة dotnet هو الطريق الصحيح ، كما تفعل جميع أدوات F # الأخرى (Paket و Fake و Fantomas و Femto و Snowflaqe). من المحتمل أن يكون الاحتفاظ بالمترجم الخرافي كتوزيع مواز أكثر إرباكًا للمستخدمين من وجود قص واضح.

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

dotnet tool install fable
npm upgrade fable-loader

من المحتمل أيضًا إضافة *.fs.js إلى .gitignore. يمكن إلغاء تثبيت fable-compiler أم لا ، ولن يتم استدعاؤه. كيف سيبدو ذلك؟ وهل سيتطوع شخص ما لصيانة محمل الخرافات الجديد؟ 😉

من المحتمل أن يكون الاحتفاظ بالمترجم الخرافي كتوزيع مواز أكثر إرباكًا للمستخدمين من وجود قص واضح.

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

أحب أداة CLI لتبسيط إنشاء تطبيقات node.js وتشغيلها بدلاً من استخدام مقسم الخرافة

نظرًا لأنهم قاموا بإصلاح تثبيت إصدار الأدوات المحلية ، فمن المحتمل أن يكون توزيع Fable 3 كأداة dotnet هو السبيل للذهاب

ربما تكون فكرة إجراء استطلاع (على تويتر على سبيل المثال) لسؤال المستخدمين الحاليين عما يفضلونه؟

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

بدون خرائط المصدر لن تكون هناك طريقة للتكامل مع تصحيح الأخطاء خطوة بخطوة في VSCode عبر launch.json ، هل هذا صحيح؟

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

لا يزال بإمكانك استخدام مصحح أخطاء VSCode ولكن لا يمكن الوصول إلى نقاط التوقف إلا في ملفات JS التي تم إنشاؤها. لقد استخدمت خرائط المصدر بشكل متكرر في كل من VSCode و Chrome (على الرغم من أن تغيير الأسماء في بعض الأحيان يجعل من الصعب تحديد القيم ، وهو أمر نحاول تحسينه في Nagareyama) ، لكنني لا أعرف ما إذا كان العديد من المستخدمين الآخرين قد فعلوا ذلك.

لم أبدأ أي رمز بعد على هذا ولكني أراقب هذا. ميلي الأول هو القيام بمنفذ مباشر من mozilla / source-map بافتراض أن هذا هو بالضبط ما هو مطلوب ولكن بعد ذلك أتساءل عما إذا كان من الأفضل استخدام C # أو F # للميناء ، فأنا أفضل اكتبها في F # بنفسي ولكن هناك بعض الفوائد في اختيار C #. في كلتا الحالتين ، سيوفر نقل المكتبة تطبيق .NET أصلي للعمل مع خرائط المصدر بشكل عام والتي قد تكون شيئًا مفيدًا لنظام .NET البيئي. في الوقت الحالي ، قمت بتقسيم المشروع بقصد إعطاء هذا الخيار فرصة في وقت فراغي المحدود.

هناك خيار آخر ربما حدث لي وهو استخدام دعم WebAssembly لمكتبة mozilla / source-map للترجمة إلى WebAssembly ثم تضمين WASM في مكتبة .NET باستخدام Wasmtime . لست معتادًا على هذا الخيار ، ولكن إذا كان يعمل ويعمل بشكل معقول ، فقد تكون طريقة أسهل للحفاظ على تزامن التنفيذ مع مكتبة خرائط المصدر الأصلية في جافا سكريبت.

هناك خيار آخر ربما حدث لي وهو استخدام دعم WebAssembly لمكتبة mozilla / source-map للترجمة إلى WebAssembly ثم تضمين WASM في مكتبة .NET باستخدام Wasmtime . لست معتادًا على هذا الخيار ، ولكن إذا كان يعمل ويعمل بشكل معقول ، فقد تكون طريقة أسهل للحفاظ على تزامن التنفيذ مع مكتبة خرائط المصدر الأصلية في جافا سكريبت.

يبدو تقريبًا أننا بحاجة إلى برنامج Java-script لـ F # transpiler ... 🤷

بكل جدية ، ستكون مكتبة خرائط مصدر F # فكرة جيدة.

https://github.com/delneg/source-map-sharp
بدأت بعض الأعمال في ترجمة https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js
هناك ، ليس أفضل رمز على الإطلاق ولكني حاولت القيام بترجمة مباشرة

هذا رائع delneg ، شكرًا جزيلاً! أعتقد أن الترجمة المباشرة تعمل بشكل أفضل حتى لو لم تكن F # اصطلاحي في حال احتجنا إلى مزامنة تحديثات المكتبة الأصلية لاحقًا: +1:

لقد قمت ببعض الأعمال (هنا https://github.com/delneg/source-map-sharp) ، ولكن قد أحتاج إلى مساعدة في وظائف "util.js" مثل util.join ، util.relative والتي تستخدم في source-map-generator.js

أنا متأكد تقريبًا من أننا لن نحتاج إلى util.getArg بسبب أمان نوع F # ، وأنا متأكد تقريبًا من أننا لن نحتاج إلى util.toSetString لأنه اختراق لتجنب الأخطاء المتعلقة بـ '__proto __'-.

من فضلك أخبرني أيضًا إذا كنا سنستخدم ذلك كـ CLI أم ...؟

شكراdelneg! سأقوم بإلقاء نظرة خلال عطلة نهاية الأسبوع وسأحاول العلاقات العامة لتلك الوظائف: +1: نعم ، سيتم استخدام المكتبة من Fable.Cli. إذا قمت بنشرها كمكتبة مستقلة ، فيمكننا فقط الرجوع إلى حزمة Nuget الخاصة بك.

لقد أنجزت معظم SourceMapNode و SourceMapGenerator وأنشأت README.md لعرض التقدم الحالي.
يمكنك أيضًا العثور على نوع المساعدة المطلوبة من أجهزة الصراف الآلي.

وفقًا للمستندات هنا https://github.com/mozilla/source-map#generating -a-source-map ، ما لدينا الآن يكفي لإنشاء خرائط مصدر ... (على الرغم من ذلك ، لست متأكدًا تمامًا من كيفية ماكينة الصراف الآلي)

هذا رائعdelneg! لقد جربته سريعًا ويبدو أنه يعمل: +1: سأحاول الآن تمكين تصحيح الأخطاء.

هذا لطيف ، هل يمكنك اقتراح الخطوات التالية؟
أي نشر nuget أو كتابة الاختبارات أو أي شيء آخر (ربما شيء من README في الريبو)
(ملاحظة: على الرغم من أنني لم أقم بنشر nuget مطلقًا ، ومن المحتمل أن يتم ذلك باستخدام حساب الخرافة)
لا عجب في PPS أنها عملت على الفور ، لقد اعتدت على ذلك أثناء استخدام F #

يجب أن تكون الخطوات التالية هي اختبار أن خرائط المصادر تعمل بالفعل من أجل تصحيح الأخطاء والقيام بالعمل الإضافي في Fable (إضافة خيار --sourceMap وحفظه في ملف`. يمكنني القيام بذلك من جانبي. وسأرسل لك أيضًا PR لتلميع API قليلاً (مثل استخدام الوسائط الاختيارية بدلاً من الخيارات الصريحة).

في الوقت الحالي ليس لدينا حساب Fable Nuget ، نحن ننشر الحزم مع حسابنا الشخصي وعادة 2-3 مالكين في حالة. إذا أنشأت حسابًا في nuget.org وأنشأت رمزًا مميزًا ، فمن السهل أتمتة النشر . يمكنني العلاقات العامة البرنامج النصي لذلك. يمكنك أيضًا إضافتي كمتعاون في الحزمة إذا كنت تريد ذلك.

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

لقد بدأت في إضافة المزيد من الاختبارات لـ SourceMapGenerator ، فقد كشفت عن بعض الأخطاء التي كانت مختبئة.
تم إصلاح بعضها الآن ، ولكن قبل أن يبدو أن جميعها بحاجة إلى الإصلاح - وإلا فقد لا تعمل التعيينات في بعض الحالات
لذلك ، من المبكر نشر أجهزة الصراف الآلي الصغيرة
إذا أراد أي شخص المساعدة - فقط ألق نظرة على الاختبارات الفاشلة ( 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 ، سأحاول أيضًا إرسال PR إلى مشروعك ، ولكن نظرًا لأن هذا سيعمل على .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 -إلى)
يمكن أن يكون الحل هو الاصطدام بشبكة الإنترنت 2.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 هو الأكثر مثالية لذلك.

FWIW ، قدم شخص ما تنفيذًا بسيطًا له على StackOverflow: stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

أعتقد الآن أنني سأصطدم به إلى 2.1 بعد ذلك ، وأترك ​​ملاحظة في README لمستخدمي netstandard2.0 المحتملين.
إذا احتاج أي شخص إلى العمل تحت الإصدار 2.0 ، فسنحصل على حل احتياطي من Stackoverflow.

تحرير: تم تحميله 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 مع netstandard2.1

قد يكون الخيار الآخر هو استبعاد الأشياء التي تعتمد على GetRelativePath بشكل مشروط (باستخدام #if) عبر الاستهداف المتعدد ، بحيث يكون كل شيء آخر متاحًا على .Net القياسي 2.0.

قد يكون الخيار الآخر هو استبعاد الأشياء التي تعتمد على GetRelativePath بشكل مشروط (باستخدام #if) عبر الاستهداف المتعدد ، بحيث يكون كل شيء آخر متاحًا على .Net القياسي 2.0.

يبدو وكأنه تعقيد مفرط لمشكلة عنوان URL نسبي بسيط (أجهزة الصراف الآلي التي تتطلب فقط GetRelativePath)

الخرافة كأداة dotnet هي netcoreapp3.1 لذا لا بأس من استهداف netstandard2.1 ، فقط قد تحتاج إلى تطبيع المسار عند التشغيل في Windows مثل 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"

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

سوف أتحقق من الأشياء المذكورة أعلاه وأتكيف مع الاختبارات من JS (هناك مجموعة كبيرة في test-util.js) ، ومن المحتمل أن نستخدم التنفيذ الخاص بنا.
أيضًا ، هناك سؤالان متبقيان:
1) ربما ينبغي علينا نقل المناقشة إلى قضايا المستودع المصدر-خريطة-حاد؟
2) هل نخطط لاستخدام تجميع WASM من نوع ما لهذا المشروع (هل هناك سبب للقيام بذلك ، لأنني لا أعرف سبب استخدام WASM في جهاز الريبو الأصلي لخريطة المصدر)؟
3) هل هناك أي شيء آخر مطلوب لـ Fable لبدء استخدام source-map-sharp ، إذا كان هناك أي شيء على الإطلاق (بما في ذلك المستندات والاختبارات و API الإضافية وما إلى ذلك)

تحرير: حسنًا ، كان ذلك سهلاً ، لقد أضفت بالفعل Util.getRelativePath المخصص ، وأضيفت الاختبارات وبعد تعديلات طفيفة أصبحت خضراء.
هل يجب أن نعود إلى netstandard2.0 بعد ذلك و / أو نشر 1.0.2 nuget؟

رهيبةdelneg! 👏 🚀 👏

  1. نعم ، من المنطقي نقل المناقشة إلى مستودع مصدر خريطة حاد: +1: يرجى ذكرني عندما تحتاج إلى مدخلاتي حتى أحصل على الإشعار.
  2. لم تتحقق من استخدام WASM في خريطة المصدر الأصلية ، لكنني أفترض أنها تستخدمه في البيئات التي تدعم WASM لتسريع العمليات الحسابية الرقمية. لا أعتقد أننا بحاجة إلى القلق بشأن ذلك في منفذ .NET.
  3. يجب أن يكون الأمر جيدًا ، لم يكن لدي الكثير من الوقت هذه الأيام ، لكنني سأحاول نشر إصدار بيتا 3.1 قريبًا مع خرائط المصدر 💪 يمكنك المضي قدمًا ونشر الإصدار 1.0.2 لذلك نستخدم هذا في الإصدار التجريبي.

تم نشر Fable 3.1 beta بدعم خريطة المصدر بفضل عمل delneg الرائع! : تادا: https://twitter.com/FableCompiler/status/1347421291502997504

رائع - من مستخدم Fable: شكرًا جزيلاً على 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) سأكتب في مشكلات الريبو بعد ذلك ، وإذا كان لدى أي شخص أي أسئلة وما إلى ذلك - يرجى فتح مشكلة في source-map-sharp
2) نعم ، أفترض أنهم استخدموا WASM لتحسين الأداء.
لقد جربت بالفعل وحصلت على إصدار WASM من عمل خريطة المصدر ، ولكن يبدو أن حالة تجميع WASM في .net فظيعة ويصعب استخدامها (يتم تنفيذ بعض الأعمال في مشروع Uno.Platform.Bootstrap ، ولكن بالنظر إليه لقد خيبتني شفرة المصدر كثيرًا)
بقدر ما يتم الاحتفاظ بتطبيق source-map-sharp على تطبيق .NET ، إذا احتجنا في أي وقت إلى مزيد من الأداء ، فيمكننا دائمًا إلقاء نظرة على Spanوغيرها من عناصر .NET لجعلها أسرع
3) لقد قمت بنشر الإصدار 1.0.2 ورأيت أنك استخدمته بالفعل ، وهذا كل شيء.
سأحاول الاستمرار في نشر Nuget في المستقبل إذا وجدنا أي أخطاء وما إلى ذلك (وحاول عدم تغيير واجهة برمجة التطبيقات)

بالنسبة لأي شخص لا يزال لا يرى خرائط المصدر بعد تطبيق الإرشادات من alfonsogarciacaro ، حاول تنظيف ملفات الإخراج (بما في ذلك جميع ملفات .fs.js ) وقم بتشغيل التصميم مرة أخرى. استغرق الأمر مني بعض الوقت لمعرفة ذلك لأن إعادة البناء دون تنظيف لم تنجح.

بخلاف ذلك ، شكرًا لجميع المعنيين لإعادة هذه الميزة الرائعة 👍

عمل رائع! عدت اليوم لأرى ما إذا كان بإمكاني متابعة هذا المشروع ومن دواعي سروري أنه قد اكتمل بالفعل. لقد قمت بأرشفة الريبو الذي بدأت به السقالات لهذا الجهد وأشرت إلى https://github.com/delneg/source-map-sharp repo في الوقت الحالي. مرة أخرى عمل عظيم!

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

et1975 picture et1975  ·  3تعليقات

rommsen picture rommsen  ·  3تعليقات

krauthaufen picture krauthaufen  ·  3تعليقات

et1975 picture et1975  ·  3تعليقات

nozzlegear picture nozzlegear  ·  3تعليقات