Jest: Поддержка RequireJS

++

В нашей дорожной карте есть поддержка надстроек модульной системы для Jest (таких как require.js, модули es6 и т. д.), но, к сожалению, мы еще не достигли этого.

Однако давайте оставим этот вопрос открытым, чтобы отслеживать прогресс — я думаю, было бы очень полезно поддерживать загрузчики require.js.

Веб-пакет @jeffmo поддерживает commonjs/es6/amd. Если бы мы могли добавить шутку в качестве плагина, мы, вероятно, могли бы получить все это бесплатно.

++

у нас есть много проектов в крупной организации, и мы планируем использовать jest, но мы на 100% требуем js. Есть ли какие-либо данные об интеграции requirejs?

++

Я также хотел бы попробовать шутку, но текущий проект, в котором я работаю, использует RequireJS.

:+1:

Кто-то предложил использовать это как прокладку, кто-нибудь пробовал?

https://github.com/Jakobo/редефин

_Возможно с оговорками_. Я реализовал небольшую сборку с nodefy в каком-то случайном репозитории, который мог бы помочь в качестве пакетах .

Лакмусовая бумажка: псевдонимы вашего модуля AMD совпадают с соответствующим модулем в node_modules . Если лакмусовая бумажка не удалась, но вы в отчаянии, вы можете использовать чистые модули AMD и/или добавить символические ссылки в node_modules, но эта идея меня огорчает. С моей точки зрения, внешние компоненты, которые я использую, имеют тенденцию реализовывать UMD и устанавливать их с помощью npm с именами, совпадающими с моими псевдонимами AMD, — в этом нет ничего страшного.

(Я проверил uRequire перед nodefy, но шаблон CommonJS делает его функционально эквивалентным nodefy — я возьму целевой инструмент. Всегда есть UMD, но кодирование UMD с разбросанными ссылками на document звучит как моветон.)

+1

++

Мы используем react, backbone и requirejs во всем нашем новом клиентском коде. Я хотел бы иметь возможность использовать шутку и облегчить часть боли тестирования. Было бы неплохо спуститься на уровень юнитов. В настоящее время наши тесты кода реакции выполняются с помощью rspec и веб-драйвера. Хотя это работает, это далеко не идеально по очевидным причинам.

Есть ли какой-нибудь практический обходной путь? Основная проблема, с которой я сталкиваюсь, - это операторы определения, которые обертывают компоненты реакции.

+1

@petehunt Повернул меня к Webpack, так что это тоже нужно учитывать.

+1

Может ли кто-нибудь указать мне пример jasmine/webpack или jest/webpack, выполняющих браузерные тесты с покрытием кода?

++

Когда мы можем ожидать поддержку requirejs?

+1

+1

+1

+1

+1

+1

Если вы используете module.exports вместо возврата для вашего вызова определения, вы можете добавить это в свой препроцессор.

У меня работает :thumbup:

// preprocessor.js
var ReactTools = require('react-tools');
module.exports = {
  process: function(src) {
    if (/define\(.*?\{/.test(src)) {
      //Remove AMD ceremony for use without require.js or almond.js
      src = src.replace(/define\(.*?\{/, '')
        .replace(/(}\);|}\))$/,'');
    }

    return ReactTools.transform(src);
  }
};

++

+1

+1

+1 за поддержку RequireJS

+1

@charliedowler Не

if (typeof(module) == 'object' && module.exports) { module.exports = <my_element>;  }

Тем не менее, я использую return , поэтому я получаю ошибку парсера от препроцессора. Я думал, что смогу уйти, расширив RegEx, чтобы он также соответствовал последнему возврату. Но, похоже, это вообще не работает. Я продолжаю получать сообщение об ошибке «недопустимый оператор возврата». Вероятно, что-то не так с выражением, и оно его не улавливает.

if (/define\(.*?\{/.test(src)) {
  src = src.replace(/(define\(.*?\{|return.*[\s]}\);?$)/g,'');  
}

Есть ли способ написать src в стандартный вывод? Простой console.log не работает.

И, наконец, если я заставлю все это работать. Как вы справляетесь с зависимостями? Например, React?

+1

Ах! Я играл с (и очень наслаждался шуткой). Сегодня попытался внедрить его в реальный проект и обнаружил, что не требуется поддержка JS :sob: ... нарушение условий сделки для всех текущих «настоящих» проектов. Грустно действительно. Это была, безусловно, захватывающая идея!

:+1:

+1

+1

:+1:

:пальцы вверх:

:+1:

:+1:

Поэтому я решил эту проблему, используя webpack для компиляции моих модулей AMD и тестов вместе. Это позволило мне также использовать всевозможные дополнительные загрузчики с моими тестами. https://github.com/ninjapanzer/Backbone-Flux-React-Webpack

:+1:

+1

+1

+1

Благодарим вас за сообщение об этой проблеме и благодарим вас за терпение. Мы уведомили основную команду об обновленной информации по этой проблеме. Мы ждем ответа в течение следующих 30 дней, в противном случае проблема может быть закрыта.

+1

@facebook-github-bot-4, пожалуйста, сделайте это!

+1

+1

++

Я работал над Jestpack, который является заменой Jest HasteModuleLoader для поддержки Webpack. В результате это означает, что вы можете использовать любую модульную систему, которую поддерживает Webpack, включая AMD.

С другой стороны, знает ли кто-нибудь о каких-либо крупных проектах с открытым исходным кодом, использующих Jest, кроме тех, которые используют модули ускорения в стиле FB, поскольку это было бы действительно полезно для тестирования производительности Jestpack?

Я также работал над jest-requirejs который является скорее попыткой стандартного препроцессора jest, который анализирует конфигурационный файл проекта main.js затем выполняет deamdify , который удаляет define Оболочка

Все еще работаю над синтаксисом плагина/загрузчика и переписываю пути jest.dontMock("") , jest.setMock("") и require.requireActual("") внутри тестовой среды.

Эй, ребята, это действительно здорово. Мне нравится идея Jestpack, и я хотел упростить поддержку дополнительных преобразователей модулей. Наконец, я также хочу обновить веб-сайт и порекомендовать такие решения, как Jestpack, как часть руководства по началу работы (которое у меня есть в голове :)). @richardscarrott и @sterpe, пожалуйста, дайте мне знать, если вам что-нибудь понадобится.

Также скопируйте @mwolson и @ColCh

(Всем остальным: пожалуйста, прекратите голосовать за комментарии, это бесполезно. Если вы хотите что-то, созданное для шутки, отправьте запрос на вытягивание. Код выигрывает аргументы! Лично я не могу расставлять приоритеты в функциях только потому, что они нужны людям в сообществе, и я не используйте _все загрузчики модулей_, которые есть у меня.).

Jestpack интересен, хотя я не сторонник создания одной точки входа для каждого теста. https://github.com/Ticketmaster/jest-webpack-alias решает проблему более общим образом, за счет некоторой предварительной обработки и возможных еще не обнаруженных ошибок из-за повторной реализации кода разрешения модуля webpack.

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

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

Это может быть, но даже первого запуска было достаточно, чтобы добавить примерно 10 секунд к выполнению нашего набора тестов.

Согласитесь, что это не быстро. В FB первый запуск занимает почти в два раза больше времени, чем последующие, но лично я не вижу другого способа решить эту проблему — мы используем babel и другие пользовательские преобразования в FB; мы не можем запускать тесты без препроцессора :)

Кэширование препроцессора кусало меня при разработке препроцессора requirejs. В основном я все еще использую jest @ 0.4, в котором, как я полагаю, не было кэширования?

С 0.5 должно работать нормально!

Webpack работает очень быстро в режиме dev-watch.

Так как:

1. Webpack хранит время выполнения в памяти (без перезагрузки)
2. Скомпилированный исходный код также находится в памяти.

Итак, в моем препроцессоре Jest я реализовал только (2) пункт.

Короче говоря , пакет ( памяти FS и выполните тестовые случаи в памяти FS .

Это моя точка зрения...

Но теперь у нас есть другая проблема: пока невозможно внедрить память FS в Jest .

Я думал об использовании API частного кеша Jest — для внедрения скомпилированного исходного кода прямо в кеш. Может это хак, так что тут я ошибся: jest-webpack/issues/4#issuecomment-98623189

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

@cpojer Я понял, что вы намеревались в конечном итоге сделать загрузчики модулей настраиваемыми, поскольку они уже были отключены, поэтому я подумал, что нанесу удар с помощью Jestpack. Единственная реальная проблема, с которой я столкнулся, заключалась в понимании логики обнаружения ручных макетов для node_modules https://github.com/facebook/jest/issues/509. В итоге я просто нашел решение, которое имело для меня смысл, но если вы Если вы можете дать какое-либо представление об этой проблеме, было бы неплохо согласовать загрузчик модулей Jestpack с HasteModuleLoader.

@mwolson Причина, по которой Jestpack использует отдельную точку входа для каждого тестового файла, заключается в том, чтобы убедиться, что он по-прежнему может использовать преимущества нескольких процессов Jest.

moduleLoader самом деле

++

Мы бы тоже этого хотели. Jest кажется отличным программным обеспечением, но не может переписать все, что у нас есть, из-за отсутствия поддержки RequireJS.

+1

Кто-нибудь из сообщества заинтересован в работе над этим? Я был бы рад поддержать людей в этом и сделать официальный плагин Jest. Маловероятно, что в ближайшее время мы в FB будем вкладывать в это значительные средства. Команда Jest очень маленькая (1,5 человека), и мы, к сожалению, не можем работать над всеми этими функциями.

Основываясь на текущем состоянии сообщества JavaScript и стандартов, не похоже, что у require js есть огромное будущее для написания кода JavaScript. Теперь у нас есть стандартизированная система модулей в ES2015. Теперь Babel и Jest полностью интегрированы и хорошо работают вместе. Я рекомендую всем перейти на модули CommonJS или ES2015, которые предоставят вам больше инструментов из коробки.

В require JS также есть документ о том, как преобразовать CommonJS в require.js, который можно использовать для производственных развертываний, см.: http://requirejs.org/docs/commonjs.html

Лично я не вижу никаких плюсов в написании кода с использованием require JS. Я также был бы рад помочь написать кодовый мод, который может помочь преобразовать

@cpojer Я несколько преуспел в подходе с препроцессором здесь https://github.com/sterpe/jest-requirejs/blob/master/index.js, но пока реализовал преобразование только для плагинов !text/. Наша команда полностью отказалась от requirejs, поэтому у меня не было причин продолжать идти по этому пути.

Я согласен, я не вижу смысла в использовании RequireJS для написания кода. Для меня имеет смысл скомпилировать код модуля CommonJS/ES2015 в requirejs для производства, но писать код в этом стиле вручную не очень удобно.

Я только что перешел с RequireJS на webpack. В нашей кодовой базе более 300 компонентов. Весь процесс прошел на удивление легко и безболезненно.

Я использовал инструмент https://github.com/Skookum/recast-to-cjs для преобразования кода из AMD в стиль CommonJS.

Также с помощью https://github.com/facebook/jscodeshift мы за несколько дней перенесли нашу кодовую базу с React 0.11 на 0.14.

Надеюсь, это может помочь кому-то в такой же ситуации.

@tendant хорошо! Это именно то, о чем я говорил раньше :) Рад, что это сработало так хорошо для вас.

Вот моя работа:
https://github.com/1twitif/testRequireJSAmdModulesWithJest
Это работает по крайней мере для этого варианта использования:
http://stackoverflow.com/questions/33889662/not-able-to-load-amd-modules-through-jest

Поскольку это закрыто, означает ли это, что Facebook не собирается добавлять поддержку для этого?

Если под фейсбуком ты меня подразумеваешь, то да, вряд ли будет "официальная" поддержка. Это не должно помешать вам внести свой вклад в Jest и получить эту функцию, но я считаю, что большинство людей в наши дни перешли на модули ES или CommonJS.

Да, знаю. К сожалению, я не могу отказаться от этих зависимостей, потому что это для работы.

babel-plugin-transform-amd-to-commonjs может оказаться полезным для решения проблемы Jest+AMD, особенно если вы уже используете что-то вроде babel-jest.

Я создал пример проекта, который показывает, как вы можете заставить Jest прозрачно запрашивать файлы AMD, запустив преобразование в тестовой среде.

Я не уверен в деталях такого подхода в реальном проекте - в частности, хороший подход для совместного использования конфигурации между Jest/RequireJS/Webpack/и т. д. Поддержка Jest файла конфигурации .js была бы шагом к более многоразовому решению (см. https://github.com/facebook/jest/issues/2140).

@msrose это потрясающе. Большое спасибо, что поделились этим.

Я понимаю, что это старая проблема. Может работать простое преобразование:

exports.process = function (content) {
  return 'function define(name, deps, body) { module.exports = body.apply(undefined, deps.map(require)); }' + content;
}

Я думаю, что преобразование AMD -> CJS может быть выполнено несколькими способами, например, deamdify , внедренная оболочка и т. д. Проблема, которая до сих пор не решена, заключается в синтаксисе загрузчика/плагина в стиле Require. Это такие вещи, как fooTemplate = require('tpl!foo.tpl') и barJson = require('json!bar.json') (как относительно распространенные). Но их было довольно много, и проекты require-js реальном мире замусорены таким синтаксисом.

Было бы здорово, если бы был простой способ напрямую повторно использовать существующие плагины require-js в системе преобразования, которые в конечном итоге загружаются в загрузчик модулей jest |.

+1

ReferenceError: define is not defined

+1

ОШИБКА srcApp.test.js
● Не удалось запустить набор тестов.

ReferenceError: define is not defined

Вы должны использовать umd вместо amd. Если это невозможно, вы должны добавить преобразование (например, подключаемый модуль babel, ссылка на который приведена выше).

Что касается синтаксиса loader! , мы его не поддерживаем (мы также не поддерживаем его для Webpack). Обходной путь — преобразовать импорт (удалив загрузчики) и позволить Jest преобразовать его, используя его конфигурацию transform . Связанное обсуждение: #4868