сейчас меня сбил с понталыку path '../../../store' — это не похоже на на path который резолвит броузер грузя native modules (и в github по этому path от u-news.js ничего нет)… я правильно понимаю что резольвилка модулей этот path тоже отрезолвит по правилам в то что нужно? т.е. не только npm packages она поддерживает? меня вообще то что в исходниках path означает «что угодно» — угнетало бы. напрашивается давать имена, а потом транспиля давать path по каким либо устанволенным для данной сборки правилам…
Уточню, а ваши модули всегда с точным path в импорте так? Важно для понимания, что отказ от условного «webpack» полный. Речь не идет об одновременной поддержке и бандла (скажам для прода) и es6 native modules (скажем для дева). Хочешь так, хочешь так.
Извиняюсь за много вопросов, у меня тут реально аналитический паралич. Хочется выйти.
Озадачили… ну не бабель, так что-то там есть раз есть и проблема «одному в импортах нужно path, а другому npm пакет»… Или все просто: тот инструмент, что из коробки, когда из node_module в wwwroot/libs копирует — тогда и подменяет имя пакета на path. А сами вы пишите модули всегда c path в импортах? Я правильно понял?
Разбить ваш код на аккуратные блоки и организовать его как вашей душе угодно вы можете с помощью нативных модулей.
Cформулировал ограничение: заменить загрузку `script src` (загрузку бандлера) загрузкой ES6 модулей `script type=«module»` неполучится в случае если имеет значение тот факт что script грузится синхронно, а модули — асинхронно. Т.е. в случае наличия нетривиального инлайн кода. Т.е. по-моему практически для всякой MPA ваша рекомендация неприменима, хотя может я может и не знаю как теперь готовят MPA.
На самом деле мне это тоже практически не сильно актуально, и я просто анализирую решения и их трейдофф «в голове». Поэтому и вопрос звучал так: «это чисто умозрительная проблема или как?». Допустим мы сошлись что «чисто умозрительная».
Я пока не могу понять Вас. Что бы вы делали в данном конкретном случае? Как сделать так чтобы popper был «виден»(резолвился) для bootstrap и для Es8Test.js загруженного как модуль? (Внутри Es8Test.js есть `import Popper from 'popper.js';`)
Сорсмапы не нужны для понимания транспиленного кода (наоборот — мешают, прячут ошибки бабеля), сорсмапы нужны для понимания «гдя я оказался» при вылете по ошибки (по крайней мере — мне). Поэтому мотивация как раз для старых броузеров «уметь» грузить все через `script src` остается. А три системы — загрузки перебор (prod, dev, legacy). dev и legacy хотелось бы объединить.
Есть еще один аспект, именно для дебуга под старыми броузерами у которых проблемы с sourceMap чисто теоритечески большая мотивация грузить скрипты «без бандлинга». Вы видимо своим решением говорите «это чисто умозрительная проблема, на самом деле все проблемы поддержки старых броузеров легко решаются и без сорс мапов и в коде бандла». Я правильно понимаю?
Вот вы говорите так как будто вопросов быть не может. А вопросов, конечно дурных, но сходу полно.
Ваше решение подразумевает что вы должны будете решить следующие проблемы:
1) Все пакеты (включая все сторонние) должны быть с ES6 module system. Что вообще-то специфическая ситуация. Редкий npm пакет для УИ в main field указывает js c ES6 import'ами.
2) вот у вас есть в коде `import '@babel/polyfill'` я так сходу не понимаю каким образом это в броузере разрешится в загрузку ./libs/@babel/polyfill/polyfill.js (или посчитается что `<script src=''./libs/@babel/polyfill/polyfill.js" >` произвел загрузку ) Вы соглашаетесь на «скинуть все в корневой каталог» я правильно понимаю?
3) гибридная проблема было import $ from 'JQuery' а jquery загружен в global как это будет понято броузером?
Статья поверхностная, но спасибо за возможность задать вопрос по этой фразе: «Поэтому бандлы для production-версии нам все-же понадобятся»… Алл, а что ты используешь в development версии для ускорения и упрощения (изучение поведения кода в броузере)? «Все в umd в ветке нет модулей»? require? делишь на несколько бандлов (в одном из которых твой код и только его пересобираешь)? Что-то еще?
Мой товарищ купил «для нужд ремонта». Идея была такая, например, сломалась крышечка от пульта ТВ у тещи, а он ее бац и напечатал. Но оказалось что эта крышечка ломается тут же (по шву слоев). Так что теща только злее и саркастичней стала.
В общем вопрос прочности — это еще и вопрос на какой толщине и в каких направлениях. В статье как-то не освещено. В быту требуются обычно мелкие детальки.
Возможно надо попасть в какую-то тютельку, подсовывая в параметры вызова то что надо, и компилировать внутренюю лямбду будут. Например если параметры «не дженерик» делегаты. Инетересно что FastCompile получив полное выражение без оптимизации «скомпилированная внутреннея лямбда» — тоже не смог большего чем простой Compile — хотя казалось бы- разобрал — скомпилировал — собрал — но есть какие-то сложности.
А разница по факту — ровно на порядок. Компилируешь внутренние лямбды — 2 ms, не компилируешь — 20 ms (и никакой FastExpressionCompiler, как я сказал — не исправляет — в случае моих выражений, по крайней мере)
Я сверил сериализацию jil c просто кодом записанным `.Append(«I1:»).Append(e.I1).Append(",")` и т.п. 12 атрибутов, массив 600 элеменов. Jil победил но с разницей в 30 **нано**секуд. Т.е. если сгенерировать по мете сериализатор в .cs и избавится от имитации потоковости а вызывать сериализатор в контроллере — эффективность jil будет фактически повторена. Это не считая тех случаев когда «тонкой сериализацией» получается убрать DTO — в таком случае и сейчас ComposeFormatter — эффективней. А идеал лежит в другой плоскости заменить пару Select + ToList одним ToJson(cache, IQueryable, IModel). Правда Include DSL тут уже не будет (`IQueryable` не`Include`).
Извиняюсь за много вопросов, у меня тут реально аналитический паралич. Хочется выйти.
Cформулировал ограничение: заменить загрузку `script src` (загрузку бандлера) загрузкой ES6 модулей `script type=«module»` неполучится в случае если имеет значение тот факт что script грузится синхронно, а модули — асинхронно. Т.е. в случае наличия нетривиального инлайн кода. Т.е. по-моему практически для всякой MPA ваша рекомендация неприменима, хотя может я может и не знаю как теперь готовят MPA.
Но я понял вам не актуально. ОК.
Вот мы пытаемся без webpackа грузить (то что с webpackом без проблем):
При этом внутри Es8Test.js есть `import Popper from 'popper.js';`
И конечно увидим что так не работает.
Вы конечно как-то этот случай отсекли, но я вот так не вижу и этвета на вопрос «что с этим кодом не так-то»?
Ваше решение подразумевает что вы должны будете решить следующие проблемы:
1) Все пакеты (включая все сторонние) должны быть с ES6 module system. Что вообще-то специфическая ситуация. Редкий npm пакет для УИ в main field указывает js c ES6 import'ами.
2) вот у вас есть в коде `import '@babel/polyfill'` я так сходу не понимаю каким образом это в броузере разрешится в загрузку ./libs/@babel/polyfill/polyfill.js (или посчитается что `<script src=''./libs/@babel/polyfill/polyfill.js" >` произвел загрузку ) Вы соглашаетесь на «скинуть все в корневой каталог» я правильно понимаю?
3) гибридная проблема было import $ from 'JQuery' а jquery загружен в global как это будет понято броузером?
В общем вопрос прочности — это еще и вопрос на какой толщине и в каких направлениях. В статье как-то не освещено. В быту требуются обычно мелкие детальки.
А разница по факту — ровно на порядок. Компилируешь внутренние лямбды — 2 ms, не компилируешь — 20 ms (и никакой FastExpressionCompiler, как я сказал — не исправляет — в случае моих выражений, по крайней мере)