#заметка дня
Разработка продукта с Google AppsScript в основе означает, что вместо нормального API у вас будет вызов функций через объект google.script.run.
Я завернул это в Promise, но вот проблема: хочется же разрабатывать локально с комфортом, накидать JSON с тестовыми данными от сервера, замокать глобальные переменные и стор (приложение гибридное). Конечно, удобнее всего просто эти данные импортировать.
Но очень не хотелось бы, чтобы замоканные данные попали в итоговую сборку. Значит, надо модули эти на лету заменять.
Вторая похожая проблема — это A/B-тесты: одним пользователям показываем одно, другим — другое. А собирать хотим из одних исходников.
И вот эту проблему решает модуль webpack с простым названием NormalModuleReplacementPlugin.
Документация модуля максимально проста, но я бы хотел обратить внимание вот на такой момент: не стоит привязываться в названиях таких модулей к среде выполнения (development/production). Вы можете очень легко случайно заменить вообще все загружаемые модули, где есть слово development, например.
Также обратите внимание на путь до модуля. В моём приложении одни и те же компоненты могли импортироваться из разных его частей и собираться отдельно, что делало почти невозможным указывание от корня. Эту проблему придётся решать отдельно на уровне разрешения путей.
В итоге, я остановился на таком подключении и пока доволен:
Подменяю глобальный стор и моки на их пустые альтернативы и всё прекрасно работает.
Быстрой сборки вам! Кстати, об этом: хочу достичь того же на Parcel 2. Знаете, как? Делитесь!
#webpack #build #module
Разработка продукта с Google AppsScript в основе означает, что вместо нормального API у вас будет вызов функций через объект google.script.run.
Я завернул это в Promise, но вот проблема: хочется же разрабатывать локально с комфортом, накидать JSON с тестовыми данными от сервера, замокать глобальные переменные и стор (приложение гибридное). Конечно, удобнее всего просто эти данные импортировать.
Но очень не хотелось бы, чтобы замоканные данные попали в итоговую сборку. Значит, надо модули эти на лету заменять.
Вторая похожая проблема — это A/B-тесты: одним пользователям показываем одно, другим — другое. А собирать хотим из одних исходников.
И вот эту проблему решает модуль webpack с простым названием NormalModuleReplacementPlugin.
Документация модуля максимально проста, но я бы хотел обратить внимание вот на такой момент: не стоит привязываться в названиях таких модулей к среде выполнения (development/production). Вы можете очень легко случайно заменить вообще все загружаемые модули, где есть слово development, например.
Также обратите внимание на путь до модуля. В моём приложении одни и те же компоненты могли импортироваться из разных его частей и собираться отдельно, что делало почти невозможным указывание от корня. Эту проблему придётся решать отдельно на уровне разрешения путей.
В итоге, я остановился на таком подключении и пока доволен:
new webpack.NormalModuleReplacementPlugin(
/(window|mocks)\.dev/,
function (resource) {
resource.request = resource.request.replace(
/dev/,
'production'
);
}
),
Подменяю глобальный стор и моки на их пустые альтернативы и всё прекрасно работает.
Быстрой сборки вам! Кстати, об этом: хочу достичь того же на Parcel 2. Знаете, как? Делитесь!
#webpack #build #module
webpack
NormalModuleReplacementPlugin | webpack
webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.
👍3
#заметка дня
Разработка продукта с Google AppsScript в основе означает, что вместо нормального API у вас будет вызов функций через объект google.script.run.
Я завернул это в Promise, но вот проблема: хочется же разрабатывать локально с комфортом, накидать JSON с тестовыми данными от сервера, замокать глобальные переменные и стор (приложение гибридное). Конечно, удобнее всего просто эти данные импортировать.
Но очень не хотелось бы, чтобы замоканные данные попали в итоговую сборку. Значит, надо модули эти на лету заменять.
Вторая похожая проблема — это A/B-тесты: одним пользователям показываем одно, другим — другое. А собирать хотим из одних исходников.
И вот эту проблему решает модуль webpack с простым названием NormalModuleReplacementPlugin.
Документация модуля максимально проста, но я бы хотел обратить внимание вот на такой момент: не стоит привязываться в названиях таких модулей к среде выполнения (development/production). Вы можете очень легко случайно заменить вообще все загружаемые модули, где есть слово development, например.
Также обратите внимание на путь до модуля. В моём приложении одни и те же компоненты могли импортироваться из разных его частей и собираться отдельно, что делало почти невозможным указывание от корня. Эту проблему придётся решать отдельно на уровне разрешения путей.
В итоге, я остановился на таком подключении и пока доволен:
Подменяю глобальный стор и моки на их пустые альтернативы и всё прекрасно работает.
Быстрой сборки вам! Кстати, об этом: хочу достичь того же на Parcel 2 или Vite. Знаете, как? Делитесь!
#webpack #build #module
Разработка продукта с Google AppsScript в основе означает, что вместо нормального API у вас будет вызов функций через объект google.script.run.
Я завернул это в Promise, но вот проблема: хочется же разрабатывать локально с комфортом, накидать JSON с тестовыми данными от сервера, замокать глобальные переменные и стор (приложение гибридное). Конечно, удобнее всего просто эти данные импортировать.
Но очень не хотелось бы, чтобы замоканные данные попали в итоговую сборку. Значит, надо модули эти на лету заменять.
Вторая похожая проблема — это A/B-тесты: одним пользователям показываем одно, другим — другое. А собирать хотим из одних исходников.
И вот эту проблему решает модуль webpack с простым названием NormalModuleReplacementPlugin.
Документация модуля максимально проста, но я бы хотел обратить внимание вот на такой момент: не стоит привязываться в названиях таких модулей к среде выполнения (development/production). Вы можете очень легко случайно заменить вообще все загружаемые модули, где есть слово development, например.
Также обратите внимание на путь до модуля. В моём приложении одни и те же компоненты могли импортироваться из разных его частей и собираться отдельно, что делало почти невозможным указывание от корня. Эту проблему придётся решать отдельно на уровне разрешения путей.
В итоге, я остановился на таком подключении и пока доволен:
new webpack.NormalModuleReplacementPlugin(
/(window|mocks)\.dev/,
function (resource) {
resource.request = resource.request.replace(
/dev/,
'production'
);
}
),
Подменяю глобальный стор и моки на их пустые альтернативы и всё прекрасно работает.
Быстрой сборки вам! Кстати, об этом: хочу достичь того же на Parcel 2 или Vite. Знаете, как? Делитесь!
#webpack #build #module
webpack
NormalModuleReplacementPlugin | webpack
webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.
👍8👎1
This media is not supported in your browser
VIEW IN TELEGRAM
#инструмент дня
Давайте честно, процесс сборки откровенно раздражает.
Да, мы живём в 2023 году и вполне можем себе позволить использовать импорты и модули вообще без транспиляции кода и сборки.
Вот только с тем же кодом на React (да и не только, JSX сейчас много где) так не получится.
Плюс, естественно, у сырого импорта есть куча собственных проблем, Андрей Ситник писал об этом тред, а у меня, конечно, имеется выжимка.
К счастью, есть некое решение! И это решение — https://esm.sh/
Это автоматический сборщик и хостинг модулей на Deno в одном флаконе, если уж совсем грубо.
И вот недавно они релизнули новую часть проекта — поддержка кода, задекларированного в тегах script. Кривовато написал...
Давайте я сразу покажу пример: https://codepen.io/alinaki/pen/NWoERwW
Что тут происходит?
1. Запихиваю приложение в
Тип такой нужен, чтобы браузер исполнять не полез.
2. Чуть выше импортирую скрипт для «сборки» (какая ирония): https://esm.sh/run
3. ...
4. Работает!
5. В примере я объявил importmap чтобы писать названия модулей так, будто у меня есть package.json. Но esm и просто ссылки поддерживает, дублируя npm и обогащая своими плюшками.
Штука забавная, на самом деле. Можно хостить самому, не опираясь на CDN.
Изначально я пробовал другой их продукт, build. Он собирает модули на лету, весьма удобно, рекомендую. Правда, немного задолбался с тем, что среда требует чёткого указания MIME-типа файла, а GitHub Pages отдают jsx как text/jsx и так далее. И настроить нельзя :( Так что для такого проекта надо брать полновесный хостинг.
Так или иначе, оно завелось! Для демок точно прекрасно, для кода, требующего ремонт на лету — тоже, вполне.
#js #module #esm
Давайте честно, процесс сборки откровенно раздражает.
Да, мы живём в 2023 году и вполне можем себе позволить использовать импорты и модули вообще без транспиляции кода и сборки.
Вот только с тем же кодом на React (да и не только, JSX сейчас много где) так не получится.
Плюс, естественно, у сырого импорта есть куча собственных проблем, Андрей Ситник писал об этом тред, а у меня, конечно, имеется выжимка.
К счастью, есть некое решение! И это решение — https://esm.sh/
Это автоматический сборщик и хостинг модулей на Deno в одном флаконе, если уж совсем грубо.
И вот недавно они релизнули новую часть проекта — поддержка кода, задекларированного в тегах script. Кривовато написал...
Давайте я сразу покажу пример: https://codepen.io/alinaki/pen/NWoERwW
Что тут происходит?
1. Запихиваю приложение в
<script>, указывая тип text/babel (так повелось, что тогда VS Code его подсветит).Тип такой нужен, чтобы браузер исполнять не полез.
2. Чуть выше импортирую скрипт для «сборки» (какая ирония): https://esm.sh/run
3. ...
4. Работает!
5. В примере я объявил importmap чтобы писать названия модулей так, будто у меня есть package.json. Но esm и просто ссылки поддерживает, дублируя npm и обогащая своими плюшками.
Штука забавная, на самом деле. Можно хостить самому, не опираясь на CDN.
Изначально я пробовал другой их продукт, build. Он собирает модули на лету, весьма удобно, рекомендую. Правда, немного задолбался с тем, что среда требует чёткого указания MIME-типа файла, а GitHub Pages отдают jsx как text/jsx и так далее. И настроить нельзя :( Так что для такого проекта надо брать полновесный хостинг.
Так или иначе, оно завелось! Для демок точно прекрасно, для кода, требующего ремонт на лету — тоже, вполне.
#js #module #esm
👍5🤩5
#заметка дня
Хочу сказать пару слов про файлы-реэкспорты aka index.js. В англоязычном сегменте разработчиков их ещё бочками зовут — barrels. Кори Хауз сегодня в тви напомнил :)
Задачи бочки просты:
✅ Сократить путь импорта
✅ Дать возможность импортировать несколько модулей из одного места
✅ Предоставить некий публичный контракт.
Мол, если вы используете что-то не задекларированное в index.js — сами себе злобные буратины.
Вот только минусов-то побольше будет:
🚫 Раздувает бандл, ведь тришейкинг становится невозможным
🚫 Потребление памяти тоже возрастает, обработать-то файл надо
🚫 Замедляет сборку
🚫 Мешает навигации по коду, когда опция "перейти к определению" кидает тебя в реэкспорт.
В общем, я перестал создавать их и планирую грохнуть из существующего кода.
Вот правило для ESLint чтобы найти у себя это в коде и больше так не делать: https://github.com/christianvuerings/eslint-plugin-no-re-export, там же есть и побольше информации.
А у вас дела как, котаны?
#js #ts #module
Хочу сказать пару слов про файлы-реэкспорты aka index.js. В англоязычном сегменте разработчиков их ещё бочками зовут — barrels. Кори Хауз сегодня в тви напомнил :)
Задачи бочки просты:
✅ Сократить путь импорта
✅ Дать возможность импортировать несколько модулей из одного места
✅ Предоставить некий публичный контракт.
Мол, если вы используете что-то не задекларированное в index.js — сами себе злобные буратины.
Вот только минусов-то побольше будет:
🚫 Раздувает бандл, ведь тришейкинг становится невозможным
🚫 Потребление памяти тоже возрастает, обработать-то файл надо
🚫 Замедляет сборку
🚫 Мешает навигации по коду, когда опция "перейти к определению" кидает тебя в реэкспорт.
В общем, я перестал создавать их и планирую грохнуть из существующего кода.
Вот правило для ESLint чтобы найти у себя это в коде и больше так не делать: https://github.com/christianvuerings/eslint-plugin-no-re-export, там же есть и побольше информации.
А у вас дела как, котаны?
#js #ts #module
❤16👍5