Информационный портал по безопасности » Программирование » Веб-разработка » SystemJS 0.20 — Совмещая с браузерными модулями

 

SystemJS 0.20 — Совмещая с браузерными модулями

Автор: admin от 26-01-2017, 10:20, посмотрело: 380

Это перевод поста в блоге Гая Бедфорда — основного разработчика таких замечательных инструментов, как JSPM — менеджера пакетов для браузеров и NodeJS, который работает на основе его же детища SystemJS — асинхронного загрузчика JS модулей любых известных форматов, способного расправляться в том числе с циклическими зависимостями, и который, в свою очередь, основан на его же детище под названием es-module-loader, полифиле для загрузки ES модулей. Как я понимаю, автор довольно сильно переписал SystemJS в данном релизе, и об этом будет интересно почитать хабраюзерам.


SystemJS 0.20 только что зарелизился — это полная его переработка, а также коррекция спецификации проекта, в то время как ES модули уже находятся прямо здесь, в браузерах.


SystemJS изначально был разработан ещё в 2013-м году для проекта jspm, в то время когда RequireJS был лидирующим загрузчиком модулей. Параллельно, быстрыми темпами, развивался ES6, и модули ES6 всё ещё казались нематериальным сном. Идея была простой и убедительной: модули приходят в браузеры, так что вы должны иметь возможность загружать любой модуль в любое время из браузера, что дало бы очень простой процесс разработки.


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


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


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


В основном, это такой случай, SystemJS 0.20 представляет очередной релиз регулировки спецификации.


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


Выравнивание спецификации


Дорога практически чиста для и синтаксиста динамического import(), спасибо авторам спецификации за тяжёлую работу.


SystemJS всегда представлял из себя следование за спецификацией загрузчика WhatWG, который, фактически, некоторое время находился в застое. То что мы видели с и динамическим import() — это плоды работы WhatWG загрузчика, но идущего из небольших фаз спецификации. Эти возможности всегда присутствовали на дорожной карте WhatWG, и представляли собой постепенное уточнение функций загрузчика — что-то вроде модели поезда из спецификации ES7+, поверх монолитной спецификации ES6.


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



  • Модульные скрипты: Описаны в спецификации WhatWG HTML, реализовано в Safari Preview и Edge Insider

  • Модульные воркеры: Описаны в спецификации WhatWG, реализуются в настоящее время

  • Синтаксис динамических импортов: Третий этап спецификации TC39, реализуются в настоящее время


Другие возможности от спецификации загрузчика WhatWG или то, что до сих пор обсуждается и до сих пор неопределено, но может быть в будущем, включают в себя:



  • Метаданные импорта: Возможность получить путь к текущему модулю, что-то вроде __filename в NodeJS

  • Хуки резолвера: Возможность перехватить браузерный механизм определения скрипта. В настоящее время, конструкция import 'jquery' завершится с ошибкой для скрипта модуля, соответствующего спецификации загрузки модулей WhatWG. Хук может добавить возможность сказать браузеру

    resolve('lodash') -> 'https://cdn.com/lodash/4.17.4/lodash.js'

    . Одно из огромных преимуществ такого подхода — это кеширование: локальный app.js, который импортирует lodash, может быть закеширован, вне зависимости от обновлений lodash.

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

  • Хук инстанцирования: Это хук, который делает возможным перехватить процесс загрузки и установить, какой модуль должен быть возвращён по указанному URL. Это также включает поддержку устаревших модулей в загрузчике — возможность загрузить AMD или CommonJS модули.


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


SystemJS идёт очень близко с этой дорогой, так что удаление этих хуков представляет собой одно из ломающих совместимость изменений проекта — больше нет возможности поймать событие System.fetch или System.transate. Вместо System[System.constructor.resolve] и System.instantiate[System.constructor.instantiate] стали новыми только два хука.


Короче говоря, SystemJS 0.20 основан на упрощённых предположениях хука резолвера и API реестра в браузерах, основанных на спецификациях и предложениях указанных выше будущих возможностей.


Для получения более точных деталей об этих API, вы можете изучить проект загрузчика модулей на https://github.com/ModuleLoader/es-module-loader, который внимательно детализирует все эти решения спецификаций и компромиссы.


Совместимость с модулями NodeJS


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


Это изменение заключается в том, что именованные экспорты больше не будут разрешены при импорте модуля CommonJS из ES-модуля, и всё это обсуждается на https://github.com/nodejs/CTC/pull/60/files#diff-2b572743d67d8a47685ae4bcb9bec651R217


То есть, конструкция import { name } from 'cjs.js, где cjs.js — это модуль CommonJS — больше не будет поддерживаться, вместе этого потребуется import cjs from 'cjs.js'; cjs.name. Это будет жёсткий разрыв, влияющий на пользователей NodeJS и Babel во многих местах, поэтому SystemJS принимает этот удар прямо сейчас.


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


Так что, если модуль cjs.js написан следующим образом:


exports.__esModule = true;

exports.name = function () {  ... }

То это даст возможность получить import { name } from 'cjs.js', даже если cjs.js будет являться модулем CommonJS, хотя в долгосрочной перспективе это также в итоге будет упразднено.


Билды для продакшена


Принимая сокращение проекта как шаг вперёд, новый продакшн-билд SystemJS был разработан для оптимальной загрузки и производительности на продакшене.


В окружении разработки, загрузчик имеет дело с проблемой загрузки неизвестных модулей, т.е. мы имеем проблему конфигурации — как вы получите конфигурацию пакета, который ещё не загружен? И по этой причине SystemJS получил полноценную систему управления конфигурацией, включающую в себя возможность динамической подгрузки конфигураций для файлов в браузере как часть разрешения, почти как package.json файлы, которые загружаются в NodeJS.


Удаление всех этих удобств разработки сокращает продакшн билд до всего 5KB. Там обеспечивает загрузку модулей System.register и System.registerDynamic, плюс базовый урл, пути, карты, контекстные карты, бандлами и поддержкой кеша зависимостей.


Изоморфные браузерные модули — polyfil-like подход


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


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


Я ссылаюсь на этот подход как на изоморфные браузерные модули, потому что с использованием System.register как с форматом модуля, версия полифила может поддерживать точную семантику выполнения ES модуля в поддерживаемых браузерах.


Был составлен демонстрационный пример на https://github.com/guybedford/isomorphic-browser-modules, основанный на продакшн билде SystemJS 0.20, который демонстрирует работу этого механизма загрузки ES модулей в Safari Technology Preview и возврат обратно на SystemJS когда нативные модули не поддерживаются.


Улучшения модульных подходов разработки


SystemJS продолжает идти по этой дороге, оптимизируя загрузку на продакшене и работая с модулями в браузерах, в окружениях нативных модулей, которые, мы надеемся, также будут продолжать развиваться. Одним из слабых мест SystemJS в данный момент является отсутствие инструментов вокруг проекта от сервера разработки до оптимизированного продакшена.


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


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


Спасибо всем, кто поддерживал и вкладывался в развитие SystemJS. Если у вас есть желание поддержать проект любым способом — у нас всегда есть пространство для работы, в том числе денежные пожертвования также приветствуются.



Источник: Хабрахабр

Категория: Программирование / Веб-разработка

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
  • bowtiesmilelaughingblushsmileyrelaxedsmirk
    heart_eyeskissing_heartkissing_closed_eyesflushedrelievedsatisfiedgrin
    winkstuck_out_tongue_winking_eyestuck_out_tongue_closed_eyesgrinningkissingstuck_out_tonguesleeping
    worriedfrowninganguishedopen_mouthgrimacingconfusedhushed
    expressionlessunamusedsweat_smilesweatdisappointed_relievedwearypensive
    disappointedconfoundedfearfulcold_sweatperseverecrysob
    joyastonishedscreamtired_faceangryragetriumph
    sleepyyummasksunglassesdizzy_faceimpsmiling_imp
    neutral_faceno_mouthinnocent