Рекомендации, которым вы, возможно, захотите следовать, если публикуете библиотеку компонентов пользовательского интерфейса.

Эта проблема

У мира JavaScript есть уникальная особенность: он имеет несколько сред выполнения, в которых работает один и тот же код. С одной стороны, у нас есть браузеры, предоставленные разными производителями и в разных версиях. С другой стороны, у нас на сервере запущены Nodejs, тоже в разных версиях. (Примечание: вы, вероятно, захотите обратить внимание на Deno, интересную среду выполнения сервера).

После почти двух десятилетий гибернации языка JavaScript получил огромную популярность, и новые функции стали появляться в языке ежедневно (ну, ежегодно, но в этом случае метафора работает лучше). В то же время появились новые разновидности JS, такие как Typescript и Flow, добавившие дополнительный синтаксис к языку.

В итоге мы получаем смесь диалектов, платформ исполнения и развивающихся стандартов. Все это приводит к тому, что создать пакет компонентов пользовательского интерфейса на Javascript и поделиться им со всем миром совсем не просто.

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

Что тогда поставить?

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

Я расскажу о доставке посылки в следующих 4 аспектах. Но стоит заметить, что они взаимосвязаны.

  • Формат синтаксиса ES
  • Формат модуля
  • Объединение файлов
  • Распространение пакетов

Вы также заметите, что обсуждение полностью не зависит от фреймворка. Обсуждаемые здесь рекомендации относятся к кросс-фреймворку и относятся к компонентам, написанным на Angular, React и Vue.

Формат синтаксиса ES

Большинство веб-браузеров, а также Nodejs поддерживают синтаксис как минимум ES2015, и большинство из них постоянно обновляются и обновлены по новым функциям языка. Печально известным исключением является IE11, доля которого на рынке, к счастью, сокращается. Если явная поддержка IE11 не требуется, можно предположить, что ES2015 можно рассматривать как лингва-франка среды JS. Также могут быть приемлемы современные браузеры и новые форматы NodeJ, такие как ES2017.

Рекомендация:

Используйте ES5, если вы ориентируетесь на старые браузеры, ES2015 или ES2017 для современных браузеров и NodeJS.

Формат модуля

Только в 2015 году Javascript или Ecamscript, как он официально известен, имел норму для формата модуля - формат модуля ES6 (AKA ESM, модули ES2015). Во время этой сумеречной зоны сообществом было создано несколько форматов, но не было единого стандарта, которого следовало бы придерживаться.

форматы были созданы для поддержки браузеров и NodeJS.

  • AMD (определение асинхронного модуля) - Requirejs описывает причины его разработки еще в 2011 году. Https://requirejs.org/docs/whyamd.html
  • CommonJS / CJS - разработан для серверных модулей.
  • UMD (Universal Module Definition) - это шаблон для поддержки как клиента, так и сервера, сочетающий AMD с CJS.
  • Модули ESM / ES / Модули ES6 / Модули ES2015 - стандартный формат, представленный в ES6. Поддержка в NodeJS 14 все еще является экспериментальной, а до этого была отмечена флагом (- экспериментальные модули).

В этой таблице приведены некоторые различия между форматами:

Чтобы почувствовать разницу, мы посмотрим, как код Typescript компилируется в разные форматы:

Рекомендация:

Создайте свою библиотеку в нескольких форматах: ESM, CJS и UMD / AMD.

Объединение файлов

При распространении в виде пакета NPM для приложений на базе браузера или сервера допустимо предоставить каталог с несколькими файлами. Сервер может легко прочитать их один за другим, в то время как браузер, скорее всего, будет иметь подготовительный этап, который объединяет все приложение в один файл (или разбивает его на части).

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

Рекомендация:

Предоставляйте форматы UMD в одном файле для браузера и форматы ESM / CJS в отдельных файлах и в одном формате.

Распространение пакетов

Большинство пакетов доступно через реестр NPM. Это распространенный метод их публикации. Публикация пакета в NPM также делает его доступным в CDN для непосредственного использования в браузере (через теги скрипта).

Рекомендация:

Убедитесь, что ваш пакет предоставляет формат UMD, поэтому он также доступен через unpkg.

Примечание. Скоро появится новый CDN, поддерживающий формат модуля ES. Посмотрите на Pika.dev !.

Инструменты

Инструменты для создания этих файлов:

  • Транспилеры
  • Бандлеры
  • Манифест (package.json)

Транспилеры

Для кода, написанного в современных форматах ES или Typescript, вам следует использовать транспиляторы Babel или Typescript. Оба они поддерживают синтаксис JS и синтаксис TS, но с некоторыми отличиями .

Babel включает плагины преобразования, которые преобразуют код, такие как transform-modules-commonjs и transform-modules-umd. Они сгенерируют соответствующий формат модуля.

Компилятор Typescript также может создавать различные форматы, используя свойство «module» в tsconfig.json, которое отвечает за создание соответствующего вывода модуля.

Бандлеры

Сборщики обычно запускают плагины, которые выполняют транспиляцию. Это включает язык и формат модуля, но также создает дополнительные ресурсы, такие как CSS и изображения.

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

Общие инструменты:

Webpack до версии 4 может создавать только пакеты UMD и CommonJS. Он также содержит несколько более подробных определений (например, CommonJS2). Подробности читайте здесь.

Накопительный пакет - это другой пакет. Rollup может экспортировать модули ES как выходной формат.

Эта статья суммирует различия (по состоянию на 2017 год…), но с выводом, который, вероятно, все еще актуален: используйте Webpack для приложений и Rollup для библиотек.

Манифест

Package.json - это способ показать содержимое библиотеки. Помимо имени версии, он должен указывать на соответствующие файлы в каталоге или пакете.

К сожалению, поскольку официального стандарта нет, некоторые специальные инструменты используют согласованные свойства для разных целей:

Некоторые атрибуты на заметку:

  • main: должен указывать на основной файл (по умолчанию index.js находится в корне). Для файлов, которые переносятся, он должен указывать на папку dist, например dist / index.js. Обычно это должно указывать на пакет CJS, так как это наиболее распространенный формат.
  • модуль: он должен указывать на точку входа или файл ES. Компоновщики, такие как Webpack, знают, что нужно искать эту запись при компоновке. Использование ES6 для связывания может улучшить дрожание дерева.
  • браузер: должен указывать на запись AMD / UMD. Обычно один файл.
  • typings: указывает на определения типов, используемых компилятором Typescript. Это файл d.ts. например dist / index.d.ts
  • unpkg: указывает на единственный файл UMD, доступный через CDN. Unpkg использует это свойство, если оно существует, или возвращается к main.
  • тип: установка в поле типа значения модуля заставляет узел идентифицировать его как ESM и пытаться загрузить его как таковой.

Заключение

Надеюсь, что в будущем, в ближайшем будущем, мы, вероятно, увидим, что экосистема Javascript сведена к стандартному формату синтаксиса и модулей.

Совместное использование и управление повторно используемыми JS-компонентами с помощью Bit

Используйте Bit (Github) для совместного использования, документирования и управления повторно используемыми компонентами из разных проектов. Это отличный способ увеличить повторное использование кода, ускорить разработку и создавать масштабируемые приложения.



Связанные истории