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, как бы это выглядело конкретно? Вы можете сделать прототип?

У нас все еще есть собственная реализация require (необходимая для моков), так что я не думаю, что это сильно поможет.

И нам нужно работать как с правилами Node, так и с правилами браузера.

Я был бы очень рад, если бы меня исправили, и чтобы он работал у нас идеально: D

@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 я начал чаще запускать сборку только потому, что Rollup находит эти ошибки, а Jest с es2015-modules-commonjs - нет.

@ std / esm, по-видимому, должен просто работать с шуткой

Было бы неплохо потратить немного времени на их взаимодействие. Вполне уверен, что это хакерское решение рано или поздно сломается: https://stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens. Но если это просто вопрос разоблачения чего-то со стороны Jest, было бы здорово увидеть, что это поддерживается.

@SimenB , на мой взгляд, немедленный шаг не будет слишком сложным. Срочно нужно разрешить людям работать с модулем .mjs, даже если babel помогает за сценой тестирования. В противном случае людям, возможно, придется искать другое решение для тестирования, если они хотят использовать .mjs.

1. Исправьте свойство testMatch, чтобы разрешить поиск файла .mjs.
   (в настоящее время это не работает, даже регулярное выражение уже кажется правильным, возможно, где-то есть жесткий код, отклоняющий расширение .mjs)
2. Передайте флаг --experimental-modules при запуске node.js, чтобы он работал изначально
3. Jest должен обрабатывать .mjs точно так же, как сегодня .js (например, в jest require) - операторы импорта уже разрешены внутри .js сегодня, поэтому нужно только разрешить расширение .mjs.

Окончательное решение может быть сложным и требует времени, но оно неизбежно, не так ли?

Здравствуйте, кто-нибудь смог исправить эту ошибку?

Мы используем .mjs с опцией "node --experimental-modules". Любой обходной путь?

Мы используем .mjs с опцией "node --experimental-modules". Любой обходной путь?

Это экспериментально и не до конца проработано. По-прежнему существует множество проблем с базовыми вещами, такими как импорт встроенного модуля, которые все еще витают в воздухе. Такие проекты, как AVA, начали разрешать использование @std/esm качестве конвейера загрузчика, если он используется (в обход Babel). Может быть, шутка могла бы использовать аналогичный подход.

Поддержка @std/esm - это то, чем мы хотим заниматься, помощь в ее реализации более чем приветствуется!

@SimenB Можете ли вы поболтать на видеовстречах?

Привет @SimenB 👋

Пользователь esm предоставил демонстрацию esm + Jest, и я подумал, что это может быть хорошей отправной точкой для создания более официального пути коровы.

Обновлять:

Демонстрация esm + Jest была обновлена ​​с поддержкой базового сопоставления имен модулей .

Это круто! Спасибо, что поделился.

Нам нужно будет выяснить, где мы хотим, чтобы интеграция была. Как он будет обрабатывать файлы CSS (или другие ресурсы, отличные от js)? Это должно быть просто преобразование? А как насчет встроенного преобразования Babel? Как Jest должен вести себя со входящими загрузчиками, если он на что-то влияет?

Похоже, что может быть преимущество для альтернативного запуска шуток с поддержкой esm (или неофициального / экспериментального флага), так что мы можем добиться прогресса в чем-то подобном. Будет ли это интересно со стороны jest team?

require не реализован в раннер, он находится в самой среде выполнения. Любой вклад в создание подключаемого модуля очень приветствуется (исх. № 848).

Я уверен, что если вы можете получить ссылку на пример кода module global, а не фальшивый, который мы создаем. Не уверены, означает ли это, что модули могут протекать между тестами? Я не знаю, что esm делает с этим под капотом. Он также не обрабатывает mocks, поэтому mocks с 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 Есть новости о поддержке Jest в esm?

Привет @deepj!

Это все еще в моем списке, и количество предметов, которые я могу решить, прежде чем это сделать, сокращается. Я улучшал дополнительную поддержку Jest для тестирования модулей esm в Jest _ (хотя CJS в тестах Jest) _. На стороне Jest все еще нет ничего критически блокирующего реализации _ (так что им нечего делать) _. Microsoft, мой работодатель, тоже активно пользуется Jest, поэтому одна из моих повседневных задач - улучшить и его. Я надеюсь скоро с этим разобраться.

@jdalton Полезно знать. И спасибо за вашу работу. Я ценю это!

Очень жду этой возможности: speak_no_evil:

Пытался заставить эту функцию работать последние два часа. Существует так много частичных решений, полузадокументированных ответов, все они отличаются друг от друга ... Раньше было легко тестировать пакеты node.js.

Итак, просто добавляем babel-plugin-transform-es2015-modules-commonjs & babel-plugin-dynamic-import-node к babel-jest ?

Что случилось с этой идеей? Есть проблемы с его реализацией?

Привет @jdalton. Мне было интересно, не могли бы вы держать нас в курсе статуса этой проблемы. Извините, если я вас беспокою, но я жду этого некоторое время, и было бы лучше, если бы мы получили обновление, по крайней мере, за последние / следующие шесть месяцев. Спасибо :)

Привет @ SurenAt93!

Спасибо за терпеливость. Я надеюсь выпустить релиз к концу месяца с поддержкой Jest. При этом вы укажете esm как преобразование Jest.

Прохладный. Чем это преобразование отличается от Вавилонского?

@kenotron

Использование Jest-опции transform - это способ загрузить загрузчик esm на боковой стороне. Таким образом, хотя он технически трансформирует исходный код, он также подключает загрузчик esm .

Если вопрос больше, в чем разница между Babel и esm . Babel - это набор пакетов, которые преобразуют исходный код, одной из целей может быть синтаксис ESM. Загрузчик esm - это загрузчик с нулевой зависимостью, который имитирует среду выполнения. Таким образом, esm поддерживает такие вещи, как динамический import() , передает соответствующие спецификации test262 (временные мертвые зоны, живые привязки, предварительные ошибки и т. Д.) И поддерживает загрузку комбинации 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-components-with-jest-86e14ef499da
• См. Эту ветку: https://github.com/vuejs/vue-cli/issues/1584

Моя машина (не уверен, что это имеет значение):

• 64-разрядная версия Windows 10 Pro.
• Узел v8.9.4
• Vue: 3.2.3
• npm: 6.5.0

@kenotron

Использование Jest-опции transform - это способ загрузить загрузчик esm на боковой стороне. Таким образом, хотя он технически трансформирует исходный код, он также подключает загрузчик esm .

Если вопрос больше, в чем разница между Babel и esm . Babel - это набор пакетов, которые преобразуют исходный код, одной из целей может быть синтаксис ESM. Загрузчик esm - это загрузчик с нулевой зависимостью, который имитирует среду выполнения. Таким образом, esm поддерживает такие вещи, как динамический import() , передает соответствующие спецификации test262 (временные мертвые зоны, живые привязки, предварительные ошибки и т. Д.) И поддерживает загрузку комбинации 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 ☺️

Я оставляю здесь небольшую «точку данных», чтобы помочь вам в вашем планировании. Я понимаю, что вы все тратите свое время и навыки на решение этой проблемы. Как разработчик, я ценю ваш вклад.

Я потратил большую часть вчерашнего дня, не меньше субботы, чтобы разобраться с модулями javascript как на стороне клиента, так и на стороне сервера. ESM, CommonJS, AMD, какая путаница. Мне так и не удалось получить тест-шутку для работы с ESM, загружающим модуль (node) с использованием расширения .mjs. Я мог успешно загрузить тот же модуль на стороне клиента. Я мог бы создать узел «клиент», который использовал бы модуль с оператором импорта. Я не смог правильно настроить jest для использования одного и того же оператора импорта, с babel или без него, с esm или без него. В конце концов я переключился на ava и просто заставил его работать, следуя рецепту на их веб-сайте. Да, я следовал рецепту, я не совсем понимаю механизм, на котором работают все части. Но, по крайней мере, теперь я могу написать ESM, загружающие модули javascript и связанные с ними модульные тесты. Думаю. Я экстраполирую на основе одного единственного успеха. У них также есть рецепт подключения ava к webstorm. Но по крайней мере, они преподносят рецепты простым смертным вроде меня.

Я также понимаю, что это сообщение будет выглядеть так, как будто я ною (что отчасти и есть). Я вижу всю работу, которая уходит в шутку. Но эта поддержка ESM - убийца для меня. Думал, что вам понравится отзыв, но если нет, проигнорируйте это или попросите меня удалить его, и я это сделаю.

Есть какие-нибудь новости в свете поддержки новых модулей в выпуске v12 ?

@dandv Я vm.SourceTextModule API, что требует передачи нескольких флагов CLI в node :

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

API тоже очень низкоуровневый.

TBD.

Обсуждение в https://github.com/nodejs/node/issues/27387

Обновление: было сказано подождать, пока конструкция загрузчика модулей Node не будет заблокирована. В то же время, стандартные вещи / esm # 706 могут быть лучшим выбором.

jest - очень хорошая библиотека для тестирования. поддержка esm действительно все должно быть полным!

Обновление: было сказано подождать, пока конструкция загрузчика модулей Node не будет заблокирована. В то же время, стандартные вещи / esm # 706 могут быть лучшим выбором.

К сожалению, это не работает со шутками.

@jdalton Мы используем lodash-es , который является сборкой lodash ES Module Exports. Наш проект - это проект Angular v7, который использует Webpack v4 под капотом в качестве своего сборщика. Для тех, кто не знает, lodash-es можно поколебать с помощью Webpack v4! (◔ ౪◔) ⊃━ ☆ ﾟ. * ・.

К сожалению, это вызывает у нас проблемы, учитывая, что Jest еще не поддерживает модуль ES. Мы надеемся, что эта функция скоро станет частью Jest. Может ли кто-нибудь знать, как заставить lodash-es работать с Jest?

Jest не работает с сообщением об ошибке:

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

    SyntaxError: Unexpected token export

Наш jest.config.js

Мы также используем пакет npm jest-preset-angular .

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. Мы надеемся, что эта функция скоро станет частью Jest. Может ли кто-нибудь знать, как заставить lodash-es работать с Jest?

Скажите 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

Привет, народ,
node 12.13.0 LTS наконец-то выпущен ... есть новости по этому поводу?

@ mtsmachado8 Боюсь, команде v8 еще нужно время, потому что я вижу, что модули ESM все еще помечаются как экспериментальные ... возможно, они не прошли в дорожной карте.

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

Для немаркированного ESM этот PR действует
https://github.com/nodejs/node/pull/29866

@azder @haraldrudell, так что в основном в своем решении вы выполняете преобразование Babel для всех файлов 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 по умолчанию появилась в 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 (Я не могу напрямую ссылаться на раздел, но это «Работа в процессе» внизу)

Для тех, кто использует собственные модули и хочет использовать jest .
Пока вы работаете над этим, я предлагаю быстрое исправление для узла v. 13.2.0:
Вавилон-плагин-преобразование-по умолчанию-импорт
Использование (в _package.json_):

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

Библиотеки необходимо установить:
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

Примечание: вам не нужно использовать babel-plugin-transform-default-import, если у вас нет библиотек, в которых есть babel с именем export (или вы его не используете)

@infodusha Потрясающе :). Спасибо тебе за это.

В моем проекте он работает без плагинов:

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 я использовал

{
  "type": "commonjs"
}

в то время как в src dir:

{
  "type": "module"
}

@azder Но если вы импортируете пакет, который предоставляет commonjs с именем import в собственных модулях, вам нужно импортировать его с импортом по умолчанию, а в babel вам нужно использовать именованный импорт. Скорее всего, у вас нет таких пакетов или пакетов, которые обеспечивают экспорт es6, но не все пакеты готовы сделать это завтра.

@infodusha Скорее всего у меня нет чего сейчас? Вы пробовали то, что я написал, и обнаружили в нем проблемы, или вы просто предполагаете, что у меня проблемы с его использованием?

Приведите реальный пример, поскольку я не совсем понимаю, что вы имеете в виду под «пакетом импорта, который предоставляет commonjs с именем import в собственных модулях».

До сих пор у меня не было проблем с записью всех файлов с расширением .js где в каталоге ./src находятся "type":"module" а в каталоге "type":"commonjs" ./test "type":"commonjs" с этим:

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

Это потому, что Jest незаметно переносит модули 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";

Для использования Node ESM вам нужно поле exports в json, и в настоящее время его нет в пакете (например, lodash).

Может показаться, что ваш пример работает, но он ломается, как только один из some-module.js или another-module.js пытается import именованный модуль: они собираются сломаться на каскаде.

@damianobarbati Вы _ НЕОБХОДИМОСТЬ _ "type": "module" в package.json , без него, все .js файлы в модуле будут загружены в CommonJS.

exports используется только для ограничения того, что доступно внешним потребителям, и для условного экспорта оно абсолютно не влияет на то, будут ли файлы .js анализироваться как CommonJS или ESM .

@damianobarbati , ты ошибаешься,

Это потому, что Jest незаметно переносит модули ES в код CommonJS.

Да, я полагаюсь на причуды Jest, поэтому я использовал babel.config.js даже не добавляя babel к devDependencies

@damianobarbati

Обратите внимание, у меня есть рабочий проект, в нем я использую Jest transpiled, в то время как каталог src имеет тип модуля, обратите внимание, ./src не корень, где находится файл конфигурации babel (это CJS из-за причуд).

Кроме того, вы правы, поскольку я не импортирую ничего из NPM, то есть CJS, поскольку я не думаю, что NPM (или авторы пакета) вполне готовы для смешивания и сопоставления.

Цель моего проекта - иметь только ESM (чтобы сократить количество инструментов), поэтому Jest - единственное исключение, которое передается само по себе.

@azder что-то вроде этого? https://github.com/damianobarbati/node-jest/tree/feature/azder-test

@damianobarbati

Примерно так вот проект https://github.com/azder/clip . Обратите внимание, что в моем package.json нет "зависимостей" согласно последнему предложению выдержки из сообщения в блоге, я решил не смешивать модули ESM и CJS из NPM.

Таким образом, для нужд Jest он переносит все, что требуется от моих модулей ESM, но, возможно, потребуется дополнительная конфигурация babel для работы с каталогом node_modules .

https://medium.com/@nodejs/announcing -a-новые-экспериментальные модули-1be8d2d6c2ff

В настоящее время невозможно создать пакет, который можно использовать как через require ('pkg'), так и через import 'pkg'. В настоящее время предпринимаются усилия по решению этой проблемы, которые могут потребовать внесения изменений в вышеизложенное. В частности, Node.js может выбрать поле, отличное от «main», для определения точки входа модуля ES пакета. Хотя мы знаем, что сообщество приняло поле «модуль», маловероятно, что Node.js примет это поле, поскольку многие из пакетов, опубликованных с использованием «модуля», включают JavaScript-модуль ES, который может не оцениваться в Node.js (потому что расширения не указываются в именах файлов, или код включает операторы require и т. д.). Не публикуйте пакеты модулей ES, предназначенные для использования Node.js, пока проблема не будет решена.

См. # 9430, который я только что открыл, чтобы отслеживать поддержку в Jest. Я оставлю этот вопрос открытым для обсуждения.

@SimenB, это хороший знак! Это и упоминание модулей в примечаниях к выпуску Jest 25 дает надежду на скорейшее появление поддержки.

@SimenB, если я правильно помню, Jest не мог использовать пакеты NPM, которые публикуются только как ESM, что также вынудило включить Babel для некоторых пакетов node_modules . Это изменилось?

Вам нужно будет транспилировать импорт / экспорт, пока не появится поддержка, как пользовательский, так и библиотечный код.

@SimenB :

Вам нужно будет транспилировать импорт / экспорт, пока не появится поддержка, как пользовательский, так и библиотечный код.

В нашем случае пока что лучший способ - это следующий вариант, поскольку все наши пакеты имеют /es/ dir, но он хрупкий и может не подходить для других проектов:

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

Jest не принимает эти пакеты без преобразования, несмотря на type: module , как вы и сказали.

Вам нужно будет транспилировать импорт / экспорт, пока не появится поддержка, как пользовательский, так и библиотечный код.

Есть примерное расписание по этому поводу?
из выпуска 14 узла:

Мы уверены, что текущая реализация предлагает перспективную модель для создания модулей ESM, которая прокладывает путь к универсальному JavaScript. Пожалуйста, прочтите больше в нашей документации.

Реализация ESM в Node.js все еще является экспериментальной, но мы уверены, что очень близки к тому, чтобы называть ESM в Node.js «стабильным». Удаление предупреждения - огромный шаг в этом направлении.

как таковой я не хочу экспортировать пакеты NPM (которые вполне могут быть использованы тестами, реализующими среду тестирования JEST) с использованием commonJS гораздо дольше.

Мы отправляем экспериментальную версию Jest 25.4. Довольно много исправлений ошибок в 25.5, но это все еще не там, где должно быть. Вы можете следить за прогрессом в # 9430