Jest: يرجى النظر في إضافة دعم أصلي لوحدات ES

لدى Jest تطبيقه الخاص بـ require (https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js) ، لذلك سيكون أكثر مشاركة من مجرد دعم بناء الجملة والافتراضي للنظر في .mjs . أنا أيضًا ضد تفعيل الأعلام التجريبية.

قد يكون من الممكن تحويل import / export تلقائيًا ، لكن تنفيذ الدلالات يعد مهمة ضخمة ، وربما تم حظره لمدة عام بسبب دعم العقدة 6.

أنا أتفق مع SimenB. نحتاج إلى عدد من الخطافات من فريق العقدة لنتمكن من جعل هذا العمل مع وحدة vm. ومع ذلك ، أعتقد أننا يجب أن ندعم هذا في غضون ذلك ، ولكن ليس من خلال عكس التطبيق الأصلي الكامل ولكن بدلاً من ذلك باستخدام babel وتجميعه لطلب داخل babel-jest . أعتقد أنه لأغراض الاختبار ، سيعمل هذا بشكل جيد ولا يتعين علينا تقديم نفس الضمانات التي يحتاج وقت تشغيل العقدة إلى توفيرها على أي حال.

إذن فقط إضافة babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node إلى babel-jest ؟

نعم ، هذا ما كنت أفكر فيه.

يا رفاق ، ماذا عن دمج https://github.com/standard-things/esm ؟ إنه سريع ويحافظ على الكثير من حالات الحافة.

TrySound كيف سيبدو ذلك بشكل ملموس؟ هل يمكنك عمل نموذج أولي؟

لا يزال لدينا تنفيذ خاص بنا (مطلوب للسخرية) ، لذلك لا أعتقد أن ذلك سيساعد كثيرًا.

ونحتاج إلى العمل مع قواعد Node وقواعد المتصفح.

سأكون سعيدًا جدًا لتصحيح الأمر وجعله يعمل بشكل مثالي بالنسبة لنا: د

يبدو أن @std/esm يجب أن يعمل فقط مع الدعابة: https://twitter.com/jdalton/status/930257653292400640

هل يمكن لأي شخص أن يجربها ويعود بعلاقات عامة للمستندات؟ 🙂

أعتقد أن المستخدمين يرغبون في الحصول على الدعم في كل مكان ، لكنني وجدت أنه يعمل فقط مع تبعيات ملفات الاختبار.

// test.js
require = require('@std/esm')(module, { esm: 'js', cjs: true });
const utils = require('./utils');

// utils.js
export { default as update } from './update';

إنه أفضل ، لكنه ليس مثاليًا.

https://github.com/tarunlalwani/jest-overriding-require-function-stackoverflow

إذن مجرد إضافة babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node إلى babel-jest؟

لا أعتقد أن هذا يعد حلاً رائعًا ، لأنه لا يقوم بأي عمليات فحص "تصدير مفقودة" ذات قيمة كبيرة مع وحدات ES. على سبيل المثال ، في React repo ، بدأت في تشغيل build في كثير من الأحيان فقط لأن Rollup وجد هذه الأخطاء ولكن Jest مع es2015-modules-commonjs لم يفعل ذلك.

يبدو أن @ std / esm يجب أن يعمل فقط مع الدعابة

سيكون من الرائع استثمار بعض الوقت في إمكانية التشغيل التفاعلي الخاصة بهم. متأكد تمامًا من أن هذا الحل الاختراق سيتعطل في النهاية: https://stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens. ولكن إذا كان الأمر يتعلق فقط بفضح شيء ما على جانب الدعابة ، فسيكون من الرائع رؤيته مدعومًا.

SimenB ، في رأيي ، لن تكون الخطوة الفورية معقدة للغاية. ما هو عاجل هو السماح للأشخاص بالعمل مع وحدة .mjs ، حتى لو كانت babel تساعد في مشهد الاختبار. وإلا فقد يضطر الأشخاص إلى إيجاد حل اختبار مختلف إذا كانوا يريدون استخدام .mjs.

1. أصلح خاصية testMatch للسماح بالعثور على ملف .mjs
   (حاليًا لا يعمل حتى أن regex يبدو صحيحًا بالفعل ، ربما هناك رمز ثابت في مكان ما يرفض امتداد .mjs)
2. قم بتمرير علامة --experimental-modules عند تشغيل node.js بحيث يتم تشغيلها محليًا
3. يجب أن يعامل Jest .mjs بنفس الطريقة تمامًا مثل .js اليوم (على سبيل المثال في jest need) - يُسمح بالفعل بعبارات الاستيراد داخل .js اليوم ، لذلك تحتاج فقط إلى السماح بامتداد .mjs.

قد يكون الحل النهائي معقدًا ويستغرق وقتًا ، لكنه حتمي أليس كذلك؟

مرحبًا ، هل تمكن شخص ما من إصلاح هذا الخطأ؟

نحن نستخدم .mjs مع خيار "عقدة - وحدات تجريبية". أي حل؟

نحن نستخدم .mjs مع خيار "عقدة - وحدات تجريبية". أي حل؟

هذا تجريبي ولم يتم تجسيده بالكامل. لا يزال هناك الكثير من الاضطرابات مع الأشياء الأساسية ، مثل كيفية استيراد وحدة مضمنة ، لا تزال في الهواء. بدأت مشاريع مثل AVA في السماح باستخدام @std/esm كخط أنابيب محمل إذا تم استخدامها (تجاوز Babel). ربما الدعابة يمكن أن تأخذ نهجا مماثلا.

دعم @std/esm شيء نريد القيام به ، المساعدة في تنفيذه أمر مرحب به!

SimenB هل يمكنك الدردشة في وقت ما على Hangouts؟

مرحبًا SimenB 👋

ساهم مستخدم esm esm + عرض الدعابة ووجدت أنه قد يكون نقطة انطلاق جيدة لإنشاء مسار بقرة أكثر رسمية.

تحديث:

تم تحديث العرض التوضيحي لـ esm + Jest بدعم أساسي لتعيين اسم الوحدة .

هذا رائع! شكرا للمشاركة.

سيتعين علينا معرفة أين نريد أن يكون التكامل. كيف سيتعامل مع ملفات CSS (أو الأصول الأخرى بخلاف ملفات js)؟ هل يجب أن يكون مجرد تحول؟ ماذا عن تحويل بابل المدمج؟ كيف يجب أن يتصرف Jest عندما يتعلق الأمر باللوادر الواردة ، إذا كان يؤثر على أي شيء؟

يبدو أنه قد يكون هناك فائدة لمجتمع ما بمساهمة esm - تمكّن عداء بديل بديل (أو علم غير رسمي / تجريبي) حتى نتمكن من إحراز تقدم في شيء من هذا القبيل. هل سيكون هناك اهتمام بهذا من فريق الدعابة؟

لم يتم تنفيذ require في عداء ، إنه في وقت التشغيل نفسه. نرحب بشدة بأي مساهمات من أجل جعله قابلاً للتوصيل (المرجع # 848).

أنا متأكد من أنه يمكنك الحصول على رمز المثال jdalton مرتبطًا للعمل بدون مشاكل (أو قريبًا منه) ، يجب أن يكون بسيطًا بما يكفي لتحميله في أداة تحميل esm خلف علامة في jest نفسها. شيء واحد أراه كمشكلة هو أنه يريد module حقيقيًا عالميًا ، وليس المزيف الذي أنشأناه. ألست متأكدًا مما إذا كان هذا يعني أن الوحدات النمطية يمكن أن تتسرب بين الاختبارات؟ لا أعرف ما الذي يفعله esm به تحت الغطاء. كما أنه لا يتعامل مع السخرية ، لذا فإن السخريات ذات import ستظل تنكسر

قد تحتاج فقط إلى بعض التغيير والتبديل في كيفية ضغط Jest على CJS. على سبيل المثال ، عند الاستهزاء بالعنصر module ، بدلاً من استخدام كائن عادي ، يمكن استخدام require("module") ثم التفاف / الكتابة فوق module.require لاعتراض الطلبات والتلاعب حسب الحاجة.

تحديث:

أنا الآن أعمل على تمكين Jest خارج الصندوق باستخدام esm (مع الأمل في أن لا شيء يضطر Jest إلى القيام به بشكل مختلف) . سأستمر في التجربة خلال عطلة نهاية الأسبوع ولكن العلامات المبكرة تبدو جيدة.

jdalton أي تحديث مع التوافق esm ؟

مرحبًا JasonCust ، لقد حظي تعليقي ببعض الاهتمام!

لقد أحرزت تقدمًا في تحديد العمل المطلوب لتمكين دعم Jest في esm . في تجاربي حصلت على Jest تحميل وتقييم الاختبارات المكتوبة في ESM. العمل المطلوب على جانب اللودر esm هو جعل الطريقة التي نتعامل بها مع vm.Script تستخدم أكثر عمومية. في الوقت الحالي ، نربط ذلك بشكل أساسي باستخدام REPL والذي يفترض وحدة واحدة. علينا أن نجعل ذلك أكثر عمومية قليلاً حتى يتراجع دعم Jest. لا يبدو أنه سيتعين على Jest تغيير أي شيء. لا يزال مُصمم دعمنا vm.Script قيد التشغيل TODO الخاص بي وسيستمر معالجته قبل إصدار أشياء مثل دعم WASM التجريبي. في الوقت الحالي ، كنت أقوم بسحق الأخطاء التي ظهرت حول APM المحسّن والدعم الساخر.

نشكرك على التحديث jdalton لأنني متحمس esm مع Jest. حتى لا تزعجك أثناء عملك على هذه الأشياء ، هل هناك مهمة مقابل esm يمكننا متابعتها جنبًا إلى جنب مع التقدم؟

يمكنك الاحتفاظ بالاشتراك في هذا الموضوع لمتابعة الريبو. سيكون دعم Jest في الإصدار v3.1.0 لذا يمكنك البحث عن هذا الإصدار.

jdalton هل من أخبار حول دعم الدعابة في esm؟

مرحبًاdeepj!

لا يزال موجودًا في قائمتي وتتقلص العناصر التي يمكنني معالجتها قبل القيام بذلك. لقد قمت بتحسين دعم الدعابة التكميلي لاختبار وحدات esm ضمن Jest _ (على الرغم من CJS ضمن اختبارات Jest) _. لا يزال هناك شيء يعيق التنفيذ بشكل حاسم من جانب Jest _ (لذلك لا يوجد عمل عليهم القيام به) _. Microsoft ، صاحب العمل الخاص بي ، هو مستخدم مزعج ثقيل أيضًا ، لذا فهو أحد أهداف وظيفتي اليومية لتحسين هذا أيضًا. آمل أن أتعامل معها قريبًا.

jdalton جيد أن تعرف. وشكرا لعملكم. أنا أقدر ذلك!

أتطلع حقًا إلى هذه الميزة: speak_no_evil:

كانت تحاول تشغيل هذه الميزة خلال الساعتين الماضيتين. هناك العديد من الحلول الجزئية ، والإجابات نصف الموثقة ، وكلها مختلفة عن بعضها البعض ... كان من السهل اختبار حزم node.js.

إذن فقط إضافة babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node إلى babel-jest ؟

ماذا حدث لتلك الفكرة؟ أي مشكلة في تنفيذه؟

مرحباjdalton. كنت أتساءل عما إذا كان بإمكانك إطلاعنا على آخر المستجدات حول حالة هذه المشكلة. آسف إذا كنت أزعجتك ، لكنني أنتظر هذا لفترة من الوقت ، وسيكون من الأفضل أن نتلقى تحديثًا على الأقل خلال الأشهر الستة الماضية / المقبلة. شكرا لك :)

مرحبا @ SurenAt93!

شكرا لك على صبرك. آمل أن يكون الإصدار بحلول نهاية الشهر بدعم Jest. مع ذلك ستحدد esm كتحويل Jest.

رائع. كيف يختلف ذلك عن بابل؟

تضمين التغريدة

يعد استخدام خيار Jest transform طريقة بالنسبة لي لتحميل محمل esm جانبيًا. لذلك بينما يقوم بتحويل المصدر تقنيًا أيضًا ، فإنه يقوم أيضًا بتوصيل محمل esm .

إذا كان السؤال أكثر ما هو الفرق بين Babel و esm . Babel عبارة عن مجموعة من الحزم التي تحول المصدر ، ويمكن أن يكون بناء جملة ESM أحد الأهداف. مُحمل esm محمل بدون تبعية يحاكي بيئة وقت التشغيل. لذا فإن esm يدعم أشياء مثل الديناميكية import() ، ويجتاز مواصفات المسبقة ، وما إلى ذلك) ، ويدعم تحميل مزيج من CJS / ESM / WASM إلى الذوق بالتكوين.

jdalton شكرا لك على العمل والدعم!

tomheller ؛)

كانت تحاول تشغيل هذه الميزة خلال الساعتين الماضيتين. هناك العديد من الحلول الجزئية ، والإجابات نصف الموثقة ، وكلها مختلفة عن بعضها البعض ... كان من السهل اختبار حزم node.js.

أنا موافق.

لقد أنشأت مشروع Vue بسيطًا ، والذي يوضح المشكلة أيضًا.
https://github.com/igasparetto/vue-jest-test
لم أتمكن من تشغيله.

اتبعت التعليمات من الصفحات التالية:

• https://vuejs.org/v2/guide/unit-testing.html
• https://medium.com/@kevin_peters/unit -testing-vue-js-component-with-jest-86e14ef499da
• يرجى الاطلاع على هذا الموضوع: https://github.com/vuejs/vue-cli/issues/1584

جهازي (لست متأكدًا من أنه يجب أن يكون مهمًا):

• Windows 10 Pro إصدار 64 بت
• العقدة v8.9.4
• Vue: 3.2.3
• npm: 6.5.0

تضمين التغريدة

يعد استخدام خيار Jest transform طريقة بالنسبة لي لتحميل محمل esm جانبيًا. لذلك بينما يقوم بتحويل المصدر تقنيًا أيضًا ، فإنه يقوم أيضًا بتوصيل محمل esm .

إذا كان السؤال أكثر ما هو الفرق بين Babel و esm . Babel عبارة عن مجموعة من الحزم التي تحول المصدر ، ويمكن أن يكون بناء جملة ESM أحد الأهداف. مُحمل esm محمل بدون تبعية يحاكي بيئة وقت التشغيل. لذا فإن esm يدعم أشياء مثل الديناميكية import() ، ويجتاز مواصفات المسبقة ، وما إلى ذلك) ، ويدعم تحميل مزيج من CJS / ESM / WASM إلى الذوق بالتكوين.

kenotron هل يمكنك تزويدنا بتحديث من فضلك؟

igasparetto ، إنه عمل jdalton هو الذي يجب أن يتيح ذلك. لم أجرب هذا الحل حتى الآن.

أحدث حالة هناك على ما أعتقد هي: https://twitter.com/jdalton/status/1080627279124934661

نعم! آسف ، لقد استغرق الأمر وقتًا أطول مما أردت. محليًا ، نجحت الآن جميع اختبارات test262 ذات الصلة. أثناء الحصول على هؤلاء ، تراجعت اختبارات السيناريوهات ذات الصلة بالسخرية ، لذا كان عليّ أن أعيدهم احتياطيًا قبل أن أتمكن من إطلاق سراحهم. ليس من المستحيل التغلب عليه ، إنه يستغرق بعض الوقت فقط. أنا أقدم عرضًا في Covalence Conf في 16 يناير وأتمنى أن أحصل على بيان بحلول ذلك الوقت. في أخبار أخرى ، اعتمدت npm tink مبكرًا esm لدعمها لبناء جملة ESM 🤝.

16 يناير وأتمنى أن يكون الإصدار بحلول ذلك الوقت

jdalton آمل أن

هل حصلت على تحديث لهذا الإصدار من فضلك؟

igasparetto إنه في https://github.com/standard-things/esm/issues/97#issuecomment -454985896 وفي https://github.com/standard-things/esm/issues/706 ☺️

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

لقد أمضيت للتو معظم يوم أمس ، يوم سبت ليس أقل من ذلك ، لأصل إلى السرعة في وحدات جافا سكريبت على كل من جانب العميل والخادم. ESM ، CommonJS ، AMD ، يا لها من فوضى مربكة. لم أتمكن مطلقًا من الحصول على اختبار مزاح للعمل مع ESM في تحميل وحدة (عقدة) باستخدام ملحق .mjs. يمكنني تحميل نفس الوحدة بنجاح من جانب العميل. يمكنني إنشاء عقدة "عميل" تستخدم الوحدة مع بيان الاستيراد. لم أتمكن من تكوين jest بشكل صحيح لاستهلاك نفس بيان الاستيراد ، مع أو بدون babel ، مع أو بدون esm. لقد تحولت في النهاية إلى ava ، وحصلت للتو على العمل باتباع وصفة على موقع الويب الخاص بهم. نعم ، لقد اتبعت وصفة ، لا أفهم تمامًا الآلية التي جعلت جميع الأجزاء تعمل. ولكن يمكنني الآن على الأقل كتابة وحدات جافا سكريبت لتحميل ESM واختبارات الوحدة المرتبطة بها. أظن. أنا أستنبط على أساس نجاح واحد. لديهم أيضًا وصفة لربط ava بعاصفة الويب. لكنهم على الأقل يقدمون وصفات للبشر مثلي.

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

هل من أخبار في ضوء دعم الوحدات الجديدة في إصدار v12 ؟

dandv لقد كنت أقوم ببعض الاستقصاءات حول ما إذا كان Jest يمكنه دعم وحدات ES الأصلية في العقدة 12. وسيشمل ذلك Jest باستخدام vm.SourceTextModule API ، الأمر الذي يتطلب بعض علامات CLI ليتم تمريرها إلى node :

--experimental-modules --es-module-specifier-resolution=node --experimental-vm-modules

واجهة برمجة التطبيقات منخفضة المستوى للغاية أيضًا.

يحدد لاحقًا.

مناقشة في https://github.com/nodejs/node/issues/27387

تحديث: طُلب منه الانتظار حتى يتم إغلاق تصميم محمل وحدة Node. في الوقت الحالي ، قد يكون المعيار / esm # 706 هو أفضل رهان.

jest هي مكتبة اختبار لطيفة للغاية. دعم esm حقًا كل ما يحتاجه ليكون كاملاً!

تحديث: طُلب منه الانتظار حتى يتم إغلاق تصميم محمل وحدة Node. في الوقت الحالي ، قد يكون المعيار / esm # 706 هو أفضل رهان.

هذا لا يعمل مع الدعابة ، للأسف.

jdalton نحن نستخدم Lodash-es ، وهي عبارة عن نموذج ES Module Exports بناء اللوداش. مشروعنا هو مشروع Angular v7 ، والذي يستخدم Webpack v4 تحت غطاء المحرك كمجمع له. بالنسبة لأولئك الذين لا يعرفون ، فإن Lodash-es قابلة للاهتزاز باستخدام Webpack v4! (◔ ౪◔) ⊃━ ☆ ﾟ. * ・.

لسوء الحظ ، هذا يسبب لنا مشاكل نظرًا لأن Jest ليس لديه دعم ES Module حتى الآن. نأمل أن تكون هذه الميزة جزءًا من Jest قريبًا. أي شخص يحدث لمعرفة كيفية الحصول على lodash-ES العمل مع الدعابة؟

فشل Jest مع ظهور رسالة الخطأ:

node_modules\lodash-es\lodash.js:10
    export { default as add } from './add.js';
    ^^^^^^

    SyntaxError: Unexpected token export

jest.config.js

نحن نستخدم أيضًا حزمة npm مضبوطة مسبقًا-الزاوية .

module.exports = {
  testMatch: ['**/+(*.)+(spec|test).+(ts|js)?(x)'],
  transform: {
    '^.+\\.(ts|js|html)$': 'ts-jest'
  },
  resolver: '@nrwl/builders/plugins/jest/resolver',
  moduleFileExtensions: ['ts', 'js', 'html'],
  collectCoverage: true,
  coverageReporters: ['html']
};

لسوء الحظ ، هذا يسبب لنا مشاكل نظرًا لأن Jest ليس لديه دعم ES Module حتى الآن. نأمل أن تكون هذه الميزة جزءًا من Jest قريبًا. أي شخص يحدث لمعرفة كيفية الحصول على lodash-ES العمل مع الدعابة؟

قل لـ Jest ألا يتجاهل Lodash-es عند التحويل:

  "transformIgnorePatterns": [
    "[/\\\\]node_modules[/\\\\](?!lodash-es/).+\\.js$"
  ],

https://www.npmjs.com/package/jest-esnext

https://github.com/haraldrudell/ECMAScript2049/tree/master/packages/jest-esnext

haraldrudell وفقًا للتعليمات ، ليس من الواضح كيفية استخدام الحزمة ، حيث تقول: إنشاء ملف بجوار package.json اسمه jest.config.js content module.exports = require('jest-esnext') ، ولكن ماذا لو كان لدي تكوين بالفعل؟ كيف يتم الدمج؟

هذا هو الملف المستخدم

https://github.com/haraldrudell/ECMAScript2049/blob/master/packages/jest-esnext/config/jest.config.js

قد تتمكن من استبدال محتويات _default بمحتويات jest.config.js

اهلا ياجماعة،
تم إصدار العقدة 12.13.0 LTS أخيرًا ... هل من أخبار حول هذا الموضوع؟

@ mtsmachado8 أخشى أن فريق v8 لا يزال بحاجة لبعض الوقت بشأن هذه المسألة لأنني أرى أن وحدات ESM لا تزال تُعرف على أنها تجريبية ... لقد فشلوا في خارطة الطريق لذلك ربما.

https://nodejs.org/api/esm.html

بالنسبة إلى ESM غير المشمول ، فإن هذا العلاقات العامة في مكانه الصحيح
https://github.com/nodejs/node/pull/29866

azderharaldrudell ذلك أساسا في حل بك أن تفعل بابل التحول لجميع ملفات JS بما في ذلك تلك الموجودة في node_modules ؟

في حالتي ، اضطررت إلى استخدام الإعداد المسبق الخاص بك مباشرة لأنني لم أجد كيفية تكوين المحول مثل:

const babelPreset7Esnext = require('babel-preset-7-esnext');
const babelJest = require('babel-jest');

module.exports = babelJest.createTransformer(
    babelPreset7Esnext(undefined, {decorators: {legacy: true}})
);

تحتوي العقدة الآن على دعم الوحدة النمطية الذي تم تبديله افتراضيًا

https://github.com/nodejs/node/pull/29866

هبط الدعم الافتراضي لوحدات ECMAScript Modules في 13.2.0

https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V13.md#13.2.0

لن نعمل على هذا حتى تتوفر اللوادر. بدونها ، لا تمتلك Node الخطافات التي تحتاجها Jest لتوفير الدعم المناسب. راجع https://medium.com/@nodejs/announcing -core-node-js-support-for-ecmascript-modules-c5d6dc29b663 (لا يمكنني الارتباط مباشرة بالقسم ، لكنه "العمل قيد التقدم" في الأسفل)

بالنسبة لأولئك الذين يستخدمون الوحدات الأصلية ويريدون استخدام الدعابة .
أثناء العمل على هذا ، أقترح إصلاحًا سريعًا للعقدة الإصدار 13.2.0:
babel-plugin-transform-default-import
الاستخدام (في _package.json_):

{
  "babel": {
    "presets": [
      [
        "@babel/preset-env",
        {
          "targets": {
            "node": "current"
          }
        }
      ]
    ],
    "plugins": ["transform-default-import"]
  },
}

يحتاج Libs إلى التثبيت:
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

ملاحظة: لا تحتاج maby إلى استخدام babel-plugin-transform-default-import إذا لم يكن لديك libs يحمل اسم babel تصدير (أو لا تستخدمه)

تضمين التغريدة شكرا لك على هذا.

في مشروعي ، يعمل بدون المكونات الإضافية:

npm i --save-dev @babel/preset-env

babel.config.js (يجب تسمية هذا الشخص بذلك ، وليس .babelrc ):

module.exports = {
    presets: [
        [
            '@babel/preset-env',
            {
                targets: {
                    node: '13.2',
                },
                modules: 'commonjs',
            },
        ],
    ],

    plugins: [],
};

الحيلة هي فصل الملفات إلى أدلة واستخدام package.json المناسب فيها:

في test dir ، اعتدت

{
  "type": "commonjs"
}

بينما في src dir:

{
  "type": "module"
}

azder ولكن إذا قمت باستيراد حزمة توفر Commonjs المسماة الاستيراد في الوحدات الأصلية ، فأنت بحاجة إلى استيرادها مع الاستيراد الافتراضي وفي بابل تحتاج إلى استخدام استيراد مسمى. على الأرجح ، ليس لديك حزم من هذا القبيل ، أو حزم توفر تصدير es6 ، ولكن ليست كل الحزم جاهزة للقيام بذلك غدًا

infodusha من المحتمل أن لا أملك ماذا الآن؟ هل جربت ما كتبته ووجدت مشكلة فيه أم أنك تفترض فقط أن لدي مشاكل في استخدامه؟

قدم مثالًا فعليًا لأنني لست واضحًا في ما تقصده بعبارة "استيراد الحزمة التي توفر Commonjs المسماة الاستيراد في الوحدات النمطية الأصلية".

حتى الآن لم أواجه أية مشكلات في كتابة جميع الملفات بامتداد الملف .js حيث يوجد في الدليل ./src "type":"module" ./test والدليل "type":"commonjs" ./test "type":"commonjs" مع هذا:

const imported = require('../src/module.js').default;
const {anotherOne} = require('../src/module.js');

ذلك لأن الدعابة transpiles بصمت ES الوحدات إلى رمز CommonJS.

هذا ما أعتقد أنه يجب اختبار وحدات ES محليًا:

(async () => {
    const [
        { default: imported },
        { anotherOne },
    ] = await Promise.all([
        import('../src/some-module.js'),
        import('../src/another-module.js'),
    ]);

    // Rest of your test goes here.
})();

azder هذه هي الحلول.

أنشئ دليلًا mymodule مع package.son type=module وملفين فيه: first.js و second.js .
ثم حاول الحصول على import { first } from "mymodule";

أنت بحاجة إلى الحقل exports في مكانه في json لاستخدام Node ESM ، ولا توجد حزمة به في الوقت الحاضر (على سبيل المثال: Lodash).

قد يبدو أن المثال الخاص بك يعمل ولكنه ينكسر بمجرد أن يحاول أحدهما إما some-module.js أو another-module.js إلى import وحدة محددة: سوف ينكسرون عند التتالي.

damianobarbati أنت _ تحتاج _ "type": "module" package.json ، بدونها ، سيتم تحميل جميع ملفات .js في الوحدة النمطية الخاصة بك كـ CommonJS .

يستخدم exports فقط للحد من ما يتم عرضه للمستهلكين الخارجيين وللتصدير الشرطي ، وليس له أي تأثير على الإطلاق على ما إذا كان سيتم تحليل ملفات .js على أنها CommonJS أو ESM .

damianobarbati أنت مخطئ ، وفقًا لما قاله @ Exe-Boss ، راجع للشغل ،

ذلك لأن Jest يحول بصمت وحدات ES إلى كود CommonJS.

نعم ، أنا أعتمد على المراوغات الدعائية ، وهذا هو السبب في أنني كنت أستخدم babel.config.js بدون حتى إضافة babel إلى devDependencies

تضمين التغريدة

من فضلك لاحظ ، لدي مشروع عمل ، أستخدم فيه Jest transpiled ، بينما يحتوي دليل src على نوع الوحدة ، لاحظ ، ./src ليس الجذر حيث يوجد ملف تكوين babel (هذا هو CJS بسبب المراوغات).

أيضًا ، أنت محق لأنني لا أستورد أي شيء من NPM وهو CJS لأنني لا أعتقد أن NPM (أو مؤلفو الحزمة) جاهزون تمامًا للخلط والمطابقة.

الهدف في مشروعي هو الحصول على ESM فقط (لتقليل الدهون في الأدوات) ، لذا فإن Jest هو الاستثناء الوحيد الذي يتم نقله من تلقاء نفسه.

azder شيء من هذا القبيل؟ https://github.com/damianobarbati/node-jest/tree/feature/azder-test

تضمين التغريدة

شيء من هذا القبيل ، ها هو المشروع https://github.com/azder/clip . لاحظ أنه لا توجد "تبعيات" في package.json وفقًا للجملة الأخيرة من مقتطفات منشور المدونة ، فقد قررت عدم مزج وحدات ESM و CJS من NPM.

بهذه الطريقة لتلبية احتياجات Jest ، فإنها تقوم بترجمة ما يتطلبه من وحدات ESM النمطية الخاصة بي ، ولكن ربما ستكون هناك حاجة إلى مزيد من تهيئة babel للتعامل مع الدليل node_modules .

https://medium.com/@nodejs/announcing -a-new-تجريبية-وحدات -1be8d2d6c2ff

حاليًا ، لا يمكن إنشاء حزمة يمكن استخدامها عبر كل من تتطلب ("pkg") واستيراد "pkg". هناك جهود جارية لمعالجة هذا الأمر ، وقد تنطوي على تغييرات لما سبق. على وجه الخصوص ، قد تختار Node.js حقلاً غير "main" لتعريف نقطة إدخال الوحدة النمطية ES للحزمة. على الرغم من أننا ندرك أن المجتمع قد تبنى حقل "الوحدة النمطية" ، فمن غير المرجح أن تتبنى Node.js هذا الحقل لأن العديد من الحزم المنشورة باستخدام "وحدة" تتضمن وحدة جافا سكريبت ES التي قد لا يتم تقييمها في Node.js (لأن تم ترك الامتدادات من أسماء الملفات ، أو يتضمن الرمز عبارات تتطلب ، وما إلى ذلك). الرجاء عدم نشر أي حزم وحدة ES مخصصة للاستخدام بواسطة Node.js حتى يتم حل هذا الأمر.

الرجاء مراجعة # 9430 الذي فتحته للتو لتتبع الدعم في Jest. سأبقي هذه القضية مفتوحة للنقاش.

SimenB هذه علامة جيدة! هذا مع ذكر الوحدات في ملاحظات إصدار Jest 25 يعطي الأمل في رؤية الدعم عاجلاً.

SimenB إذا كنت أتذكر بشكل صحيح ، لم يكن node_modules أيضًا. هل تغير هذا؟

ستحتاج إلى تحويل الاستيراد / التصدير حتى وصول الدعم ، لكل من رمز المستخدم والمكتبة

SimenB :

ستحتاج إلى تحويل الاستيراد / التصدير حتى وصول الدعم ، لكل من رمز المستخدم والمكتبة

بالنسبة إلى حالتنا ، فإن أفضل طريقة حتى الآن هي هذا ، نظرًا لأن جميع حزمنا بها /es/ dir ، لكن هذا هش وقد لا يصلح لمشاريع أخرى:

transformIgnorePatterns: ['node_modules/(?!.*?/es/.*\\.js)'],

لا تلتقط Jest هذه الحزم بدون تحويل على الرغم من type: module ، تمامًا كما قلت.

ستحتاج إلى تحويل الاستيراد / التصدير حتى وصول الدعم ، لكل من رمز المستخدم والمكتبة

أي جدول زمني تقريبي على هذا؟
من إصدار العقدة 14:

نعتقد أن التنفيذ الحالي يقدم نموذج إثبات مستقبلي لتأليف وحدات ESM التي تمهد الطريق إلى Universal JavaScript. يرجى قراءة المزيد في وثائقنا.

لا يزال تطبيق ESM في Node.js تجريبيًا ولكننا نعتقد أننا اقتربنا جدًا من استدعاء ESM في Node.js "مستقر". تعد إزالة التحذير خطوة كبيرة في هذا الاتجاه.

على هذا النحو ، فأنا متردد في تصدير حزم NPM (التي قد يتم استهلاكها عن طريق الاختبارات التي تنفذ إطار اختبار JEST) باستخدام CommonJS لفترة أطول.

نحن نشحن نسخة تجريبية من Jest 25.4. عدد قليل جدًا من إصلاحات الأخطاء في 25.5 ، لكنها لا تزال في المكان الذي يجب أن تكون فيه. يمكنك متابعة التقدم في # 9430