Comments 23
ES5 (main-legacy.js) 175K
У него там там babel-polyfill подключен, если чё.
По всей видимости, наиболее правильным будет использовать подход, подобный этому: определять возможности браузера и инжектить соответствующим образом сформированный тэг script.
А у вас этот пример сколько скриптов грузит?
А вот остальные (ff, opera 12, ie11) — грузят оба. Исполняют да, один.
Тогда все же надо программно определять возможности и подключать только один скрипт.
Пришло время собирать наши модули как ES2015
Ох, как раз недавно столкнулись с такой бедой, когда «скрипя сердцем» решили дропнуть ES5-транспилирование в нашем проекте — и выяснили, что в популярных фронтенд фреймворках, типа Nuxt, в конфиге babel-loader тупо захардкодено исключение node_modules
из сборки. И включить это назад там не так-то просто бывает. Разработчики же этого Nuxt вообще не понимают, зачем кому-то может понадобиться импортировать ES6 модуль — мол, «я ни разу не видел не пред-транспилированного модуля, а значит, этого не бывает».
Причём ломается это все в итоге даже не в браузере пользователя — слава богу, основные браузеры уже умеют в ES6 — а на таких замечательных и непременных штуках в тулчейнах девелоперов, как Uglify или Google Closure Compiler. Которые в 2017 году до сих пор не умеют даже в классы, какое там async/await...
К счастью, нашу либу в основном юзают из Node, поэтому это оказалось не так страшно. Но и там нашлись свои приколы: поле engine
в package.json
, судя по всему, не работает так, как многие думают. С его помощью вы не сможете запретить устанавливать ваш пакет в ранние версии Node (где ещё не появился, скажем, async/await). Раньше в NPM был флаг engineStrict
, но теперь его убрали. И, убрав поддержку ES5 в своем проекте, мы столкнулись с тем, что многие юзеры до сих пор сидят на доисторических версиях Node и совсем не понимают, почему после npm update
у них всё вдруг перестало работать...
В целом многие JS девелоперы вообще не понимают что такое Babel и как его настраивать. Вот например тут человек целый день провозился с настройкой вебпака, в итоге обматерил меня и мой проект, и написал свой собственный аналог :)
Транспилирование библиотек должно умереть, конечно же — т.к. ES модули позволяют импортировать только ту часть кода, которая реально используется (tree shaking). В ином случае, чтобы достичь подобного, приходится разбивать большие модули на миллион маленьких микромодулей (в пределе — до уровня отдельных функций), что крайне неудобно в плане поддержки...
А Babili (babel-minify) пробовали? Единственный минификатор с поддежкой es6 кода, что я знаю.
И про поддержку доисторических Node.js. Уже давно было заявлено, что версии ниже Node 4 больше не поддерживаются. То есть они не получают вообще никаких обновлений, в том числе критических. Поддерживать их в своих библиотеках смысла нет, их уже не поддерживают множество популярных npm-модулей, например: https://github.com/request/request/issues/2772#issuecomment-330879495
А Node.js 4 много чего из ES6 понимает. Я использую ESlint с плагином node/no-unsupported-features, который понимает секцию engines из package.json и предупреждает об использовании неподдерживаемых ES6-фич
Это означает, что если авторы модулей начнут публиковать исходный код на ES2015+ в npm, то они, вероятно, сломают некоторые сборки пользователей и просто вызовут путаницу.
Было предложение добавить поле module в package.json, чтоб решить эту проблему, но пока воз и ныне там.
Развертывание кода ES2015+ в продакшн сегодня