Окончательное модульное решение JS для UMD с зависимостями?

Я поддерживаю и сотрудничаю с некоторыми модулями JavaScript, написанными на CommonJS, которые нуждаются в высококачественных оболочках UMD.

Зависимости взяты из npm, но имеют по крайней мере поддержку CommonJS и AMD (или я могу добавить).

Версия CommonJS продолжается npm Обернутый модуль UMD будет перемещен в bower

Обертка должна работать в браузерах (AMD + глобальные) и в Node.js (любые и другие системы CommonJS, если это возможно). Любая автоматизация предпочтительно должна происходить с помощью Grunt (я очень хорошо разбираюсь в grunt).

Я провел целую вечность, просматривая Google en SO, но это огромный беспорядок.

Некоторые обнадеживающие, которые не совсем подходят (или я что-то упускаю, что вполне возможно):

  • обозревать
  • клеи
  • ворчание

Я нахожу такие отчаянные конструкции повсюду: http://rathercurio.us/building-umd-modules-with-dependencies-with-browserify , но я не очень хорошо разбираюсь в таком хакерстве.

Любые хорошие советы по этому поводу? Я возьму любой указатель или ссылку или совет.

Редактировать: уточнение: последнее, что было сказано, идеальное решение не должно требовать от нас сборки кусков стандартного кода шаблона вручную и создания новых ошибок. Тем не менее, я спокойно настраиваю и определяю вещи.


module node.js amd javascript commonjs
person Bartvds    schedule 27.11.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Ваша первая и последняя остановка должна быть на urequire.org, универсальном конвертере модулей, который делает гораздо больше, чем просто конвертирует модули javascript CommonJS и AMD. в UMD (или AMD, или CommonJS, или автономный, использующий rjs/almond).

Это позволяет вам манипулировать кодом и зависимостями модуля во время преобразования: вставлять, заменять или удалять код и зависимости, экспортировать в глобальные объекты (window) или ваш пакет, вводить и, при необходимости, объединять общий код (например, инициализации), добавлять информацию о времени выполнения, минимизировать и многое другое. намного больше.

Большая часть из них использует простые, но чрезвычайно мощные объявления и, возможно, обратные вызовы для тонкой манипуляции. Он работает с отдельными файлами конфигурации (.js, .coffee, .json, .yml и т. д.) и как есть в виде конфигурации gruntjs< /а>

uRequire компилируется из исходных модулей, написанных на javascript, coffeescript, livescripted, coco и icedcoffeescript без каких-либо плагинов.

Забудьте о шаблонах, кодовых церемониях и повторяющихся требованиях. Шаблоны преобразования основаны на хорошо известных UMDjs, но их можно настроить с помощью объявлений, чтобы скрыть или предоставить функциональность.

uRequire с открытым исходным кодом, лицензия MIT и размещены на github и написаны мной :-)

person Angelos Pikoulas    schedule 11.12.2013
comment
urequire.org делает несколько смелых заявлений :), но, если предположить, что он работает, он вполне может быть Единственным. Поддерживаете ли вы также исходные карты (включая преобразование/слияние?) Я часто использую TypeScript и grunt_concat_sourcemap (оба генерируют карты) и, конечно же, предпочли бы отлаживать исходный код даже после того, как он потребовал их в AMD. - person Bartvds; 13.12.2013
comment
Что ж, попробуйте сами, если получится :-) uRequire начинался как домашний проект для простого преобразования AMD в UMD, но с тех пор было добавлено множество функций, превративших его в инструмент, который может выполнять 90% обычных задач, которые можно выполнить. найти в типичном файле grunt, затрачивая всего 10% усилий и шаблон. К сожалению, исходные карты и TypeScript — это две функции, которые еще не затронуты, но должны быть :-( - person Angelos Pikoulas; 17.12.2013
comment
Мне очень нравятся возможности UMD, это очень крутая технология. Только я всегда предпочитаю использовать свой собственный компилятор (машинописи) (здесь grunt-ts) для опытного пользователя, конкретный будет иметь больше функций, чем универсальная версия в комплекте (делает одно и делает это хорошо). Но генерация исходной карты (и преобразование) в наши дни в значительной степени необходима. Как еще мы будем отлаживать сгенерированный код? Выполняя вручную поиск из пакета через любой конвейер, который мы использовали, чтобы добраться туда? Это 2010 год :) - person Bartvds; 18.12.2013
comment
Да, я согласен с тем, что исходные карты очень популярны, и, к сожалению, у меня нет времени, чтобы реализовать их в urequire, хотя я бы хотел, чтобы они были запечены когда-нибудь в будущем. То же самое касается машинописного текста, из-за его объединения deps . Я полагаю, что если у вас есть хорошо написанные тесты (и система типов :-), вам не нужно нужно делать следующий-следующий-следующий так много против источника :-) - person Angelos Pikoulas; 19.12.2013
comment
@AgelosPikoulas есть новости об исходных картах? - person CMCDragonkai; 19.02.2014
comment
@CMCDragonkai Боюсь, пока ничего :-/ Возможно, кто-то может предоставить PR или что-то в этом роде - uRequire использует хорошо известный парсер esprima AST и генератор кода escodegen AST. - person Angelos Pikoulas; 19.02.2014