Краткая версия - для некоторых пакетов npm теперь есть соответствующий пакет в области @ esm-bundle.

Если вы ищете обновленную опубликованную версию пакета npm в формате ESM (модуль javascript) или System.register, ищите ее на https://github.com/esm-bundle или на npm на https://www.npmjs.com/search?q=%40esm-bundle.

Если пакета нет, вы можете создать репозиторий, который автоматически публикует версии ESM и SystemJS каждый раз, когда публикуется официальная версия. Для этого следуйте этим инструкциям.

Пример:

Длинная версия - нам это нужно как сообществу javascript

Модули являются частью javascript с 2015 года, но до сих пор (обычно) не используются в производственных системах. Вот причины, по которым это может начать меняться:

  1. Webpack скоро будет поддерживать компиляцию в ESM в версии 5.x.
  2. Браузеры могут скоро поддерживать псевдоним спецификатора импорта для URL-адреса. (карты импорта реализованы в Chrome за флагом функции).
  3. Межсайтовое кеширование ресурсов javascript довольно эффективно. (Правка: двойной ключевой кеш сводит на нет это преимущество).

Для первых пользователей и энтузиастов такие проекты, как import-map-service-worker, snowpack и es-module-shims - это несколько проектов, с которыми стоит познакомиться.

Но связки плохие по… причинам.

Начнем с развенчания некоторых мифов:

Миф: нельзя дерево трясти пачкой.

Это просто ложь.

Миф: однажды нам не понадобятся упаковщики

Без сборщика каждый исходный файл приводит к сетевому запросу. Американские разработчики создают слишком много файлов, чтобы это работало. Нет, здесь нас не спасет даже HTTP push.

Кроме того, кроссбраузерная совместимость никогда не исчезнет. Да, мы в основном избегали IE и часто поддерживаем только вечнозеленые браузеры. Но нам все равно нужно говорить кратко, когда мы хотим обойти странные ошибки Safari 10. И мы сообщаем babel, какие именно браузеры мы хотим поддерживать, чтобы он мог использовать свои энциклопедические знания о функциях браузера, чтобы убедиться, что все работает.

Миф: достаточно публиковать отдельные файлы ESM

Это субъективно, но, на мой взгляд, пакет, который вы можете import() в браузере из CDN, намного проще использовать в производственной среде, чем десятки исходных файлов, которые, возможно, потребуется скомпилировать и объединить перед производственным использованием.

Миф: Склеивание элементов в браузере действительно плохо сказывается на производительности по сравнению с временем сборки.

Хотя есть что сказать об оптимизации, которая может произойти только тогда, когда все обрабатывается во время сборки (удаление мертвого кода / встряхивание дерева), есть что сказать и о кэшировании действительно распространенных библиотек, таких как React и RxJS, на всех веб-сайтах, которые вы посещаете. (Правка: HTTP-кеш с двойным ключом сводит на нет этот эффект)

Кроме того, общие библиотеки, такие как React, часто вообще не получают выгоды от встряхивания дерева из-за неспособности webpack встряхивать модули CommonJS.

Наконец, огромная монолитная сборка часто не приводит к лучшим размерам пакетов из-за опыта, необходимого для управления ею.

Факт: объединение опубликованного пакета означает, что издатель выбирает целевой браузер вместо пользователя пакета.

Это правда. Вот хорошая статья от Джейсона Миллера (@developit) по этому поводу.

Подход - не ждите PR или разрешения

Поскольку у многих проектов с открытым исходным кодом нет времени, желания или людей для создания и публикации пакета ESM и System.register для своей библиотеки, я взял на себя смелость сделать это сам.

Библиотека React - хороший пример - их конфигурация накопления настолько отвратительна (ура, монорепозиторий!), Что даже самые умные участники борются через WIP PR за реакцию ESM.

Я обнаружил, что зачастую проще просто взять опубликованные артефакты npm и самому запустить их через накопительный пакет. Это не потому, что разработчики ПО с открытым исходным кодом плохо справляются со своей работой - просто сложно всегда быть на высоте.

Я решил опубликовать их в рамках npm @ esm-bundle, чтобы они были доступны через yarn add thing@npm:@esm-bundle/thing и на CDN в unpkg и jsdelivr.

Гайки и болты - пакеты autopublishing @ esm-bundle

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

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

Он состоял из пяти частей:

  1. Используйте накопительный пакет для официального пакета, который находится внутри node_modules.
  2. Используйте бота для автоматического обновления официального пакета при публикации новой версии.
  3. Используйте бота для автоматического объединения пул реквестов.
  4. Настроить CI на автоматический запуск и публикацию пакета @ esm-bundle.
  5. Настроить обширные, но многоразовые тесты, которые проверяют, что библиотеки действительно могут быть загружены как ES-модули в реальном браузере.

Управление экосистемой

Я не знаю, завоюет ли этот проект популярность, но если да, то я хотел быть готовым к тому, что как можно больше внешних участников создадут и поддержат репозитории esm-bundle.

С этой целью я создал эти инструкции о том, как внести свой вклад в новое репозиторий esm-bundle. Для начала участники будут использовать репозиторий с этим шаблоном Github. После того, как он заработает локально, они могут запросить разрешения Github, чтобы передать репо в организацию esm-bundle. После передачи переменные среды CI для публикации в npm будут предоставлены.

Неужели 2020 год, когда наконец-то будут использоваться модули ES?

Не знаю, но если да, то будем к этому готовы!