Rollup-plugin-typescript2: عرض ملف الاستيراد

هل يمكنك نشر tsconfig و rollup config؟

أو ريبو صغير مع استنساخ :)

للأسف ليس لدي ريبو "صغير". أنا أعمل هنا ، أحاول الترحيل من webpack إلى rollup .

يمكن تغيير الاستيراد في rollup.config.js إلى rollup-plugin-typescript2 لمعرفة الفرق.

مرحبا.

بادئ ذي بدء ، شكرًا جزيلاً لك على العمل على هذا المكون الإضافي. إنه بالفعل أكثر منطقية من rollup-plugin-typescript .

يمكنني التأكيد على وجود هذه المشكلة وإعداد مستودع تجريبي صغير:
https://github.com/danimoh/rollup-plugin-typescript2-vue-demo

إذا قمت بإلغاء السطر import AnotherComponent from './AnotherComponent.vue'; فإنه يتم تجميعه ، ولكن للأسف لم يتم تمكين هذا السطر.

من المضحك أننا واجهنا هذه المشكلة في نفس الوقت تقريبًا. ربما كان سببه تغيير حديث؟
التخمين من جانبي بمعرفة محدودة جدًا حول الإضافات التراكمية والتراكمية والنصوص المطبوعة ستكون:
هل من الممكن أن المطبوع نفسه يحاول استيراد AnotherComponent بدلاً من التجميع أو rollup-plugin-vue التعامل مع هذا الاستيراد أولاً؟

هذا من شأنه أن يفسر سبب عدم وجود هذه المشكلة في rollup-plugin-typescript حيث يتم تجميعها على أساس كل ملف باستخدام transpileModule .

في هذه الحالة ، قد يكون ما يلي مثيرًا للاهتمام: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#customizing -module-resolution

هو موضع تقدير كبير أي عمل بشأن هذه المسألة.

مستنسخة في كلا المستودعات ، لست متأكدًا مما إذا كانت هي نفس المشكلة حتى الآن ، ولكن من المحتمل.

لإصلاح الحالة الثانية ، نحتاج بالفعل إلى إرسال دقة الوحدة مرة أخرى إلى Rollup حتى يتمكن المكون الإضافي vue من القيام بذلك.

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

• استدعاءات التراكمي تحويل البرنامج المساعد
• يستدعي البرنامج المساعد typecript's LanguageService.getEmitOutput
• تستدعي خدمة اللغة تنفيذ المكون الإضافي LanguageHost.resolveModuleNames وتتوقع إرجاع المسارات التي تم حلها في هذه الوظيفة
• مجموعة مكالمات المضيف PluginContext.resolveId
• يُرجع التراكمي وعدًا
• إذا فهمت بشكل صحيح ، فكل ما يمكنني فعله بوعد هو أن أقدم وعدًا آخر

يبدو أن LanguageService متزامن تمامًا: https://github.com/Microsoft/TypeScript/issues/1857

يمكن أن يعيد Plugin.transform وعدًا بحد ذاته ، لكن آليات تسلسل الوعود المتعددة التي يتم إجراؤها داخل عمليات الاسترجاعات العميقة على كائن مراقب بعيدة عني في الوقت الحالي.

ذات صلة إلى حد ما: https://github.com/rollup/rollup/issues/2631

مرحبا ezolenko.

في الوقت الحاضر ، تعني الأساليب غير المتزامنة في جافا سكريبت في الغالب طرق إرجاع الوعود. بناء الجملة الجديد async / await هو أساسًا مجرد سكر نحوي للطرق غير المتزامنة التي تمكن المطور من كتابة كوده على غرار الكود المتزامن ، ولا تزال الأساليب async تعيد الوعود. await لا يمكن استخدامه إلا في async أساليب بالرغم من ذلك. كما لاحظت ، فإن الطريقة LanguageHost.resolveModuleNames ليست غير متزامنة ، وبالتالي لا يمكن العودة من هذه الطريقة إلا بعد انتظار الوعد في جافا سكريبت عادي.

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

وبالتالي ، فإن الشيء الذي يحتوي على استدعاء الطريقة غير المتزامنة ليس مشكلة كبيرة في الواقع. قد تكون هناك مشكلة أخرى بالرغم من ذلك. بينما يقدم سياق المكون الإضافي طريقة resolveId ، لن يكون هذا كافيًا. نحتاج إلى استدعاء transform من rollup-plugin-vue لاستخراج الكود المطبوع من مكونات الملف الواحد vue. لا يبدو أن سياق المكون الإضافي يقدم هذه الوظيفة لسوء الحظ.

قد تكون إحدى الطرق لحل هذه المشكلة هي إضافة rollup-plugin-vue كتبعية لمشروعك وتشغيل transform على المكوّن الإضافي vue مباشرة. هذا بالتأكيد ليس جميلًا على الإطلاق وليست الطريقة المقصودة للعمل مع الإضافات التراكمية.

قد يكون الأسلوب الآخر هو تشغيل transpileModule في transform على أساس كل ملف في التشغيل الأول للسماح لمجموعة التحديثات بجمع جميع الواردات ، دع المكون الإضافي vue transform المنفرد مكونات الملف وذاكرة التخزين المؤقت للكود المطبوع عليه المستخرج. ثم قبل انتهاء التجميع ، تخلص من الشفرة التي تم تحويلها وقم بعمل ترجمة مطبوعة مناسبة على الكود الذي قمنا بتخزينه مؤقتًا في ربط البرنامج المساعد renderChunk أو generateBundle . قد يتداخل هذا مع المكونات الإضافية الأخرى على الرغم من أن ذلك يطبق تحويلات إضافية على الكود الذي نتجاهله.

في الوقت الحالي ، لا أرى حلًا أكثر جمالًا بعد.

تحرير: في الفكر الثاني ، ربما لا يكون النهج الثاني قبيحًا. بدلاً من الخطافات renderChunk أو generateBundle ، يمكن أن يكتشف المكون الإضافي نفسه عند استيراد آخر استيراد وعند هذه النقطة يبدأ التجميع من البداية ويضيف الملف المترجم إلى قائمة انتظار التجميع بحيث يكون يمكن معالجتها بالفعل بواسطة جميع المكونات الإضافية الأخرى أيضًا. لا تزال الملفات التي تم إنشاؤها مسبقًا بحاجة إلى التخلص منها لتجنب أن ينتهي بها الأمر في الحزمة النهائية.
ومع ذلك ، فإن هذا النهج يضيع بعض وقت المعالجة لأنه يتيح للمكونات الإضافية الأخرى أيضًا الملفات التي نتجاهلها على أي حال.

danimoheddow الحل البديل لكلا المثالين من المستودعات يعمل على تعطيل التحقق من الأخطاء باستخدام // @ts-ignore فقط فوق عمليات الاستيراد المخالفة.

الخطأ هو في الأساس شكوى مطبوعة من أنه لا يعرف ما هو نوع * .vue stuff (يعني Cannot find module نوع الوحدة النمطية). بمجرد إسكات ذلك ، يبدو أن كل شيء يتم تجميعه بشكل صحيح. الجانب السلبي هو أن الأشياء المستوردة من ملفات vue لها نوع any ولا تساعد في التحقق من الأخطاء.

(في الحد الأدنى من الريبو ، يحتاج المكون الأول إلى مرجع للمكون الثاني ، وإلا فإن الأشجار المتدرجة تهزها بعيدًا عن الحزمة)

danimoh نعم ، لا توجد طريقة للحصول على مصدر الوحدة من

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

كبديل للسماح للمكوِّن الإضافي vue بمعالجة ts ، قد يكون ما يلي أسلوبًا صالحًا ونوعًا من التكرار الأفضل للاختراق القبيح الذي اقترحته سابقًا:

• هل تم عرض مثيل المكون الإضافي vue من خلال ربط options ؟
  بهذه الطريقة يمكننا استدعاء طريقة transform على المكوّن الإضافي vue.
• من https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API يبدو لي أنه يمكن تغذية ts CompilerHost و LanguageServiceHost fileExists ، readFile ، getScriptSnapshot وما شابه ذلك.
• إذا كان كلاهما يعمل ، فيمكننا السماح للطباعة على الكتابة بتحليل الشفرة التي نحصل عليها من المكون الإضافي vue إلى AST وجمع الواردات من هذا AST وطلبها من المكون الإضافي vue إذا كانت ملفات .vue . بالنسبة لجميع ملفات vue ، نقوم بتخزين الكود المطبوع عليه المستخرج مؤقتًا والكتابة فوق طرق مثل readFile لإرجاع رمز ts المخزن مؤقتًا لاستيراد vue .

تحرير: في الواقع ، إذا استطعنا الكتابة فوق fileExists و readFile ، فلن نحتاج إلى جمع الواردات بأنفسنا عن طريق اجتياز AST لأن الكتابة المطبوعة هي فقط استدعاء هذه الطرق لجميع الواردات التي تريد استيرادها على أي حال. نحتاج بعد ذلك فقط إلى استدعاء المكون الإضافي vue عند الطلب.

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

ستعمل نقطتك الثانية ، وهذا بالضبط ما يعنيه LanguageServiceHost .

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

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

أعتقد أنه لا يوجد في الواقع عمل مهمل. سوف يُجمِّع Typescript الكود مرة واحدة فقط وسيحتاج المكون الإضافي vue أيضًا إلى معالجة كل ملف مرة واحدة فقط إذا قمنا بتخزين كود ts المستخرج مؤقتًا. لا يتجاهل هذا النهج أيًا من النتائج الخاصة به أو نتائج المكونات الإضافية الأخرى بخلاف اقتراحي السابق.

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

إنه يعمل بالنسبة لي مع هذا الإعداد ، لتجميع مكون vue واحد:

import VuePlugin from 'rollup-plugin-vue'
import typescript from 'rollup-plugin-typescript2'

export default {
  plugins: [
    typescript({
      typescript: require('typescript'),
      objectHashIgnoreUnknownHack: true,
    }),
    VuePlugin(/* VuePluginOptions */),
  ],
  input: 'src/components/HelloWorld.vue',
  output: [
    { file: 'dist/HelloWorld.cjs.js', format: 'cjs' },
    { file: 'dist/HelloWorld.esm.js', format: 'esm' },
  ],
}

لست متأكدًا مما إذا كانت هذه هي أفضل طريقة لإنشاء وحدة من Vue SFC باستخدام lang = "ts".

إذا كان لدى أي شخص أي نصيحة ، فيرجى إبلاغي بذلك.

إنه يعمل بالنسبة لي مع هذا الإعداد ، لتجميع مكون vue واحد:

صحيح ، لكن هذه ليست حالة استخدام حقيقية. هذا مرحبًا بالعالم. بالنسبة لأي شخص لديه مشكلة في فهم المشكلة ، هذا ما استخلصته.

التراكمي حرفيا لا يمكن القيام بذلك

لماذا ا؟ هذا مثال:

<script lang="ts">
import Bar from './Bar.vue';
...
</script>

1) يقوم البرنامج المساعد vue بتمرير البرنامج النصي إلى المكون الإضافي من النوع
2) يواجه المكون الإضافي للطباعة على ملف .vue ، لكن ليس لديه طريقة لمعرفة ما يجب فعله به لأن التجميع لا يوفر آلية للمكونات الإضافية للتراجع إلى المكونات الإضافية الأخرى عند الاستيراد مثل webpack. يمكن تأجيل JS العادي إلى المكونات الإضافية ، ولكن لا يمكن للكود الذي تتم معالجته بالفعل بواسطة مكون إضافي.
3) في الواقع لا أفهم سبب اختلاف هذا عن lang=scss أو lang=ts ، لكن أعتقد ذلك.

حسنًا ، ماذا يمكنني أن أفعل؟

ليس كثيرا.

لكن أقنع! Buefy!

Vuetify هو نص مكتوب ، لكنه لا يستخدم SFCs. إنها وظائف تصيير خالصة.

يستخدم Buefy SFCs والتراكم ، ولكن لا يوجد نص مكتوب.

حقًا ، لا يوجد شيء يمكنني فعله؟

لن يعجبك ذلك. لكل ملف Vue تحتاج إلى استيراده من ملف مضغوط ، سيتعين عليك إنشاء وسيط ملف جافا سكريبت عادي.

import Bar from './Bar.vue';

export default Bar;

بعد ذلك وبعد ذلك فقط ، ستتمكن من إنشاء ملف SFC الخاص بك مع مجموعة التحديثات.

الجيز ، هذا سيء

إذا توصلت إلى حل أفضل ، فأنا أحب أن أسمعه.