Comments 13
Простите, но плагин для bower вроде как не нужен, webpack умеет делать это из коробки github.com/xgrommx/angular-vk-app/blob/master/gulpfile.js#L40
Всё верно, я тоже использовал изначально встроенный ResolverPlugin, пока не столкнулся с проблемой.
Возьмём пример по этой ссылке:
Как видим, этот плагин позволяет искать в директории запрошенного модуля файл bower.json и если он найден — возвращать файл, указанный в секции «main». Однако, я столкнулся с тем, что модуль bootstrap в своём описании содержит целую цепочку файлов (что логично):
Для того, чтобы подключить эти файлы и создан модуль BowerWebpackPlugin.
Возьмём пример по этой ссылке:
...
plugins: [
new webpack.ResolverPlugin([
new webpack.ResolverPlugin.DirectoryDescriptionFilePlugin("bower.json", ["main"])
])
...
Как видим, этот плагин позволяет искать в директории запрошенного модуля файл bower.json и если он найден — возвращать файл, указанный в секции «main». Однако, я столкнулся с тем, что модуль bootstrap в своём описании содержит целую цепочку файлов (что логично):
...
"main": [
"less/bootstrap.less",
"dist/css/bootstrap.css",
"dist/fonts/glyphicons-halflings-regular.eot",
"dist/fonts/glyphicons-halflings-regular.svg",
"dist/fonts/glyphicons-halflings-regular.ttf",
"dist/fonts/glyphicons-halflings-regular.woff",
"dist/js/bootstrap.js"
],
...
Для того, чтобы подключить эти файлы и создан модуль BowerWebpackPlugin.
UFO just landed and posted this here
Недавно перешел с browserify на webpack. Hot module replacement очень радует. В остальном, в моём случае, разницы особо нету. А, ну еще, gulp выпилился за ненадобностью.
Посмотрел на webpack как раз после доклада moscowjs.
Посмотрел на webpack как раз после доклада moscowjs.
Есть несколько моментов, которые меня сильно смущают:
1. entry-point почему-то является одним файлом. Причём, на сколько я понял, js-файлом. Хотелось бы указывать папку.
2. Если я подключаю скрипт из модуля, то ожидаю, что подключится и css и прочие файлы. Но на сколько я понял, каждый файл должен быть достижим через ссылки из других фалов. Это ворох копипасты.
3. К js безусловно добавляется webpack бутстрап, даже если он там не нужен (не используется require, например).
Буду рад, если скажете, что я ошибаюсь по всем трём пунктам :-)
1. entry-point почему-то является одним файлом. Причём, на сколько я понял, js-файлом. Хотелось бы указывать папку.
2. Если я подключаю скрипт из модуля, то ожидаю, что подключится и css и прочие файлы. Но на сколько я понял, каждый файл должен быть достижим через ссылки из других фалов. Это ворох копипасты.
3. К js безусловно добавляется webpack бутстрап, даже если он там не нужен (не используется require, например).
Буду рад, если скажете, что я ошибаюсь по всем трём пунктам :-)
1. Это с одной стороны непривычно и кажется глупым, особенно для пользователей concat решений (например Sprockets). Но на деле вы явно строите дерево зависимостей начиная от вершины-entry и это очень упрощяет работу с большими проектами а так же ускоряет вход новых людей тк всегда и без проблем можно понять как работает приложение. Но если вам нужно просто взять и включить содержимое определенной папки — webpack это позволяет с помощью контекстов.
2. Это очень просто реализуется с помощью webpack, можете посмотреть как мы это решили для своего проекта: component-resolver-webpack & component-css-loader.
3. Бутстрап webpack — необходимое зло, но зло небольшое:
Источник
Важно понимать что это не просто concat утилита, а очень мощный менеджер зависимостей который многие вещи делает проще, но тем не менее требует инвестиций. Если вы не знаете зачем вам модульность, то вполне вероятно вам и не нужен webpack.
2. Это очень просто реализуется с помощью webpack, можете посмотреть как мы это решили для своего проекта: component-resolver-webpack & component-css-loader.
3. Бутстрап webpack — необходимое зло, но зло небольшое:
243b + 20b per module + 4b per dependency
Источник
Важно понимать что это не просто concat утилита, а очень мощный менеджер зависимостей который многие вещи делает проще, но тем не менее требует инвестиций. Если вы не знаете зачем вам модульность, то вполне вероятно вам и не нужен webpack.
1. Что мешает директории быть этой самой вершиной entry? Или, на худой конец, какому-нибудь ini-файлу? И вообще, я хочу иметь возможность любой модуль со всеми его файлами оформить в виде независимой библиотеки. То есть чтобы подключились все файлы модуля и все необходимые им зависимости.
Это какая-то чёрная магия. Я хочу простую вещь — чтобы модуль подключался целиком или же не подключался вовсе. Без шаманств.
2. Довольно костыльное решение
Бывает много скриптов и мало стилей или много стилей но мало скриптов или и стилей и скриптов мало, зато много шаблонов. Привязка к именам файлов ни к чему хорошему в этих случаях не приведёт.
3. От чего же необходимое? Если используются рантайм фичи вебпака — безусловно. Но если не используются — зачем их пихать? На мой взгляд стоит разделить проект на:
а) собственно сборщик, который собирает исходники
б) рантайм библиотека, как один из исходников, которая подключается как и все остальные исходники — по наличию зависимости.
И да, я знаю зачем мне модули
require("./template/" + name + ".jade");
Это какая-то чёрная магия. Я хочу простую вещь — чтобы модуль подключался целиком или же не подключался вовсе. Без шаманств.
2. Довольно костыльное решение
component-css-loader modifies original component source code and adds require('component_name.styl') at the first line.
Бывает много скриптов и мало стилей или много стилей но мало скриптов или и стилей и скриптов мало, зато много шаблонов. Привязка к именам файлов ни к чему хорошему в этих случаях не приведёт.
3. От чего же необходимое? Если используются рантайм фичи вебпака — безусловно. Но если не используются — зачем их пихать? На мой взгляд стоит разделить проект на:
а) собственно сборщик, который собирает исходники
б) рантайм библиотека, как один из исходников, которая подключается как и все остальные исходники — по наличию зависимости.
И да, я знаю зачем мне модули
1. Да, без проблем. Но если в директорию вы решите поместить readme-файл? А если тесты для него? Как это исключать? Действительно логичней и чище было бы декомпозировать, исходя из того, что есть модуль, в котором указаны его основные зависимости. У тех в свою очередь могут быть другие. Например:
— в этом случае webpack подключит шаблон, CSS и фоновое изображение. При этом вы можете спокойно и без проблем создавать документацию, разные сценарии сборки, тестирования и пр.
Другой вариант — использовать подход для подключения bower-модулей, изложенный в статье. Он без проблем подключит bower.json с таким фрагментом (реальный пример из жизни — компонент ladda-bootstrap):
Тут важно осознавать, что модуль должен вернуть что-то — объект или функцию. В случае со списком выше — тут просто. А вот если вы подключите по вашему примеру заведомо неизвестный набор jade-шаблонов, как вы с ними будете работать? В случае с webpack — один шаблон = одна функция:
2. Во многом ответил в предыдущем пункте. Согласен про то, что если есть проект, в котором для модулей много CSS-файлов, то будет затратно их подключать по отдельности — тут можно либо собрать всё предварительно через gulp/grunt, либо написать плагин по образу и подобию:
github.com/lpiepiora/bower-webpack-plugin
И всё сообщество будет вам благодарно! С webpack вообще всё возможно. Он разве что кофе не готовит.
3. Require.js так и был устроен — там это вынужденная необходимость, ведь сборщик немаленький. Но в случае с webpack, как kossnocorp, речь идёт о 243 байтах — мы на HTTP-запрос к отдельному загрузчику можем больше потерять.
var componentTemplate = require('./component.jade');
require('./component.css');
module.exports = contentTemplate;
.my-custom-component {
background: url(./bg.png');
}
— в этом случае webpack подключит шаблон, CSS и фоновое изображение. При этом вы можете спокойно и без проблем создавать документацию, разные сценарии сборки, тестирования и пр.
Другой вариант — использовать подход для подключения bower-модулей, изложенный в статье. Он без проблем подключит bower.json с таким фрагментом (реальный пример из жизни — компонент ladda-bootstrap):
...
"main": [
"dist/ladda-themeless.css",
"dist/ladda.js"
],
...
Тут важно осознавать, что модуль должен вернуть что-то — объект или функцию. В случае со списком выше — тут просто. А вот если вы подключите по вашему примеру заведомо неизвестный набор jade-шаблонов, как вы с ними будете работать? В случае с webpack — один шаблон = одна функция:
var messageTemplate = require('./template/message.jade');
$('#messages').append(messageTemplate({userName: 'vintage', ...});
2. Во многом ответил в предыдущем пункте. Согласен про то, что если есть проект, в котором для модулей много CSS-файлов, то будет затратно их подключать по отдельности — тут можно либо собрать всё предварительно через gulp/grunt, либо написать плагин по образу и подобию:
github.com/lpiepiora/bower-webpack-plugin
И всё сообщество будет вам благодарно! С webpack вообще всё возможно. Он разве что кофе не готовит.
3. Require.js так и был устроен — там это вынужденная необходимость, ведь сборщик немаленький. Но в случае с webpack, как kossnocorp, речь идёт о 243 байтах — мы на HTTP-запрос к отдельному загрузчику можем больше потерять.
Когда я смотрел его пол года назад он добавлял куда больше 243 байт мусора. Думаю мне стоит сделать второй подход к с наряду. Может удастся допилить до юзабельного состояния.
> Но если в директорию вы решите поместить readme-файл? А если тесты для него? Как это исключать?
Очень просто — правильно именуя файлы. Например:
request.env=node.js — реализация для ноды
request.env=web.js — реализация для браузера
request.stage=test.js — универсальные тесты
> Но если в директорию вы решите поместить readme-файл? А если тесты для него? Как это исключать?
Очень просто — правильно именуя файлы. Например:
request.env=node.js — реализация для ноды
request.env=web.js — реализация для браузера
request.stage=test.js — универсальные тесты
Опять же, имеется ввиду сборка для продакшн = после минимизации.
«Правильно» — это очень относительно, у каждого ведь своё «правильно». У меня оно немного другое. Не лучше, не хуже — просто другое. Поэтому тут было бы удобней сделать плагином, они как раз для таких случаев предназначены. Это действительно просто.
«Правильно» — это очень относительно, у каждого ведь своё «правильно». У меня оно немного другое. Не лучше, не хуже — просто другое. Поэтому тут было бы удобней сделать плагином, они как раз для таких случаев предназначены. Это действительно просто.
webpack и кофе готовит :) github.com/webpack/coffee-loader
Здесь был комментарий, который я перенёс выше. Не нашёл кнопки удаления.
Sign up to leave a comment.
webpack: 7 бед — один ответ