Краткая версия - для некоторых пакетов 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 года, но до сих пор (обычно) не используются в производственных системах. Вот причины, по которым это может начать меняться:
- Webpack скоро будет поддерживать компиляцию в ESM в версии 5.x.
- Браузеры могут скоро поддерживать псевдоним спецификатора импорта для URL-адреса. (карты импорта реализованы в Chrome за флагом функции).
- Межсайтовое кеширование ресурсов 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 автоматически публиковались каждый раз, когда публикуется официальная версия.
Он состоял из пяти частей:
- Используйте накопительный пакет для официального пакета, который находится внутри node_modules.
- Используйте бота для автоматического обновления официального пакета при публикации новой версии.
- Используйте бота для автоматического объединения пул реквестов.
- Настроить CI на автоматический запуск и публикацию пакета @ esm-bundle.
- Настроить обширные, но многоразовые тесты, которые проверяют, что библиотеки действительно могут быть загружены как ES-модули в реальном браузере.
Управление экосистемой
Я не знаю, завоюет ли этот проект популярность, но если да, то я хотел быть готовым к тому, что как можно больше внешних участников создадут и поддержат репозитории esm-bundle.
С этой целью я создал эти инструкции о том, как внести свой вклад в новое репозиторий esm-bundle. Для начала участники будут использовать репозиторий с этим шаблоном Github. После того, как он заработает локально, они могут запросить разрешения Github, чтобы передать репо в организацию esm-bundle. После передачи переменные среды CI для публикации в npm будут предоставлены.
Неужели 2020 год, когда наконец-то будут использоваться модули ES?
Не знаю, но если да, то будем к этому готовы!