16 декабря 2014 в 13:27

webpack: 7 бед — один ответ из песочницы

После моего недавнего выступления на MoscowJS #17 с одноимённым докладом у многих возник интерес к этому инструменту. В рамках 11-го выпуска RadioJS, Миша Башкиров bashmish рассказал, что решился попробовать его в своём новом проекте, об успешном опыте и множестве положительных эмоций. Но были озвучены вопросы и возникла дискуссия, в результате которой я решил написать эту статью, чтобы раскрыть основные тезисы с доклада и рассказать о том, что тогда не успел.
Статья ориентирована, как на профессионалов, так и на тех, кто с похожими технологиями ещё не сталкивался.
Итак, начнём.

7 бед


Современный мир веб-разработки открывает перед нами, как невероятные возможности, так и проблемы. По масштабу их можно разделить на два:

  • Глобальные проблемы отрасли веб-разработки.
  • Локальные проблемы наших проектов.

Глобальные проблемы


  1. Разрозненность решений. HTML5 и JavaScript окончательно развязали нам руки. Новые и революционные решения создаются чуть ли не каждый день. У каждого своя специфика, преимущества и недостатки. При этом все они созданы для решения небольшого, по сути, круга задач:

    • jQuery, Knockout, Angular, Marionette, React — если оттолкнуться от деталей, всё это создано для решения одних и тех же задач.
    • Underscore, lodash, Lazy, ES6 — во многом, для работы с данными.
    • MVC, MVVM, Flux — даже архитектурные паттерны созданы для решения одной задачи.

  2. Разнообразие версии этих решений на порядок увеличивает масштаб озвученной проблемы:

    • Один плагин требует jQuery 1.8, второй — jQuery 2.1. Что делать?
    • Angular 1.3 и Angular 2 — почти полностью разные.
    • Bootstrap 2.3 и Bootstrap 3.1 — компоненты, созданные для одной версии не встанут из коробки для другой.

  3. Форматы для пре-процессинга (сюда же контейнеры), например:

    • LESS, SCSS, SASS, Stylus — для стилей.
    • Handlebars, jade, EJS — для шаблонов.
    • JSON, JSON5, PJSON, XML — для данных.
    • CoffeeScript, JSX, ES6 — скрипты и т.д.

Как это отражается в реальной работе?

Локальные проблемы


  1. Сложность роста проекта:
    • Функциональная — создать прототип, добавить раздел, сделать форму, связать разделы между собой и т.д.
    • Технологическая — перейти на Bootstrap, подключить Leaflet, внедрить React и т.д.
  2. Управление зависимостями. Когда в проекте появляются хотя бы 3 скрипта, начинается жонглирование — постоянно приходится задумываться:
    • Загружены ли библиотеки?
    • А необходимые стили?
    • А шаблоны?
    • Если это jQuery-плагин, загружен ли для него jQuery?
    • А необходимые стили?
    • А шаблоны?
    • А какие ещё необходимы ему библиотеки?
  3. Управление версиями (суть проблемы описана выше).

Какое решение?


Наиболее оптимальное решение — разбивать код на изолированные модули. Исторически для этого сложилось два подхода — AMD и CommonJS. О них уже многое писали и говорили, но приведу краткий обзор (кто знаком — может пропустить).

AMD (Asynchronous Module Definition)

Сводится к определению модуля через define() и вызову через require():

define(['jquery', 'products'], function ($, products) {
	return {
		show: function () {
			products.forEach(function (item) {
				$('.items').append(item.html);
			});
		}
	};
});

Достаточно удобно. Но при росте зависимостей это превращается в спагетти-код. Поэтому разработчики добавили CommonJS-обёртку:

define(function (require, module, exports) {
	var $ = require('jquery');
	var products = require('products');
	module.exports = {
		show: function () {
			products.forEach(function (item) {
				$('.items').append(item.html);
			});
		}
	};
});

Подробней об этом хорошо изложено в статье от Виталия Чиркова clslrns.

CommonJS

Нативно реализован на серверном JavaScript в Node.js/Rhino.
Сводится к определению модуля через глобальную переменную и вызову через require():

var $ = require('jquery');
var products = require('products');
module.exports = {
	show: function () {
		products.forEach(function (item) {
			$('.items').append(item.html);
		});
	}
};

Основные преимущества перед AMD:
  • Повышенная читаемость.
  • Упрощённое написание.
  • Изоморфность (один код, как для браузера, так и для сервера):

    var _ = require('lodash');
    var data = require('./stock.json');
    module.exports = _.where(data, function (item) {
    	return item['count'] > 0;
    });
    

Подробней об этом рассказывал в своём докладе Антон Шувалов из Rambler.

Оба эти подхода позволяют:

  • Создавать и использовать изолированные модули.
  • Не думать о порядке загрузки.
  • Безопасно подключать сторонние решения.
  • Использовать разные версии библиотек.
  • Собирать из нескольких модулей один JS-файл.

Так что же теперь? Что воплотит наши фантазии в жизнь? Что лучшее мы имеем на сегодняшний день?

Встречайте — webpack


Вы только представьте. Любая логика. Любые форматы. Ваш проект быстро собирается. Ваш проект быстро загружается. Вы имеете самые развитые инструменты разработки. А теперь давайте взглянем поближе.

Быстрое начало


Для эксперимента, создадим директорию src и в ней простой скрипт index.js:

console.log('Hello Habrahabr!');

Договоримся, что в директории assets будут наши выходные файлы (скрипты, стили, используемые ими изображения). Это те самые файлы, которые мы можем выложить на наш веб-сервер, CDN и т.д.

Глобально есть две стратегии использования webpack:

  • через консоль (подходит для небольших проектов);
  • через скрипт в качестве Node.js-модуля.

В обоих случаях, нам понадобится Node.js и npm. Если ещё не сделали это ранее — самое время установить их сейчас.

Использование через консоль

Для этого нам понадобится установить webpack глобально:
npm install webpack -g

После этого, сборка осуществляется простой командой:
webpack src/index.js assets/bundle.js

Использование в качестве модуля

Это наиболее подходящая стратегия для средних и крупных проектов.
В директории проекта создаём package.json. Это можно сделать командой:

npm init

Добавляем в проект модуль webpack:

npm install webpack --save-dev

Для сборки проекта создаём Node.js-скрипт. Например, build.js:

var path = require('path');
var webpack = require('webpack');
var config = {
	context: path.join(__dirname, 'src'), // исходная директория
	entry: './index', // файл для сборки, если несколько - указываем hash (entry name => filename)
	output: {
		path: path.join(__dirname, 'assets') // выходная директория
	}
};
var compiler = webpack(config);
compiler.run(function (err, stats) {
	console.log(stats.toJson()); // по завершению, выводим всю статистику
});

Запускаем сборку:

node build


Результат

В обоих случаях мы получаем директорию assets и в ней bundle.js — это наш собранный файл, в котором содержится сам index.js и все подключаемые им зависимости. В примере выше, он у меня был размером 1528 байт.
Для его использования нам не нужен никакой дополнительный загрузчик, поэтому достаточно подключить только этот файл:

<!doctype html>
<html>
<body>
	<script src="assets/bundle.js"></script>
</body>
</html>

Вот всё и заработало. Полноценно webpack может раскрыться, только через конфигурацию, поэтому далее я не буду приводить примеров для консоли, однако, открыть для себя всю магию консоли Вы без проблем можете в документации.

Плагины


Одна из главных точек расширения webpack — это плагины. Они позволяют менять 'на лету' логику сборки, алгоритм поиска модулей, иными словами, залезать в самое сердце процесса сборки.
Подключение происходит через добавление секции plugins в передаваемых настройках.

Примеры плагинов:

  • webpack.optimize.UglifyJsPlugin — минификации кода с использованием UglifyJS.

    Настройка (build.js):

    ...
    	plugins: [
    		new webpack.optimize.UglifyJsPlugin(),
    ...
    

    После добавления этих строк, файл bundle.js в примере выше уменьшается с 1528 до 246 байт.

  • webpack.optimize.DedupePlugin — удаление дубликатов модулей. Если Вы, например, используете сторонние Node.js-библиотеки, то с большой вероятностью некоторые используемые ими модули могут быть продублированы. Этот плагин находит дубликаты модулей и удаляет их. Это не влияет на стабильность кода, но может существенно сократить размер собранного файла.

  • webpack.DefinePlugin — определение констант и выражений внутрь кода. Как в старом добром C++.

    Настройка (build.js):

    ...
    	plugins: [
    		DefinePlugin({
    			'NODE_ENV': JSON.stringify('production')
    		}),
    ...
    

    Использование (index.js):

    if (NODE_ENV === 'production') {
    	console.log('There is Production mode');
    } else {
    	console.log('There is Development mode');
    }
    

    При сборке этот код будет преобразован в следующий вид:

    if (true) {
    	console.log('There is Production mode');
    } else  {
    	console.log('There is Development mode');
    }
    

    А если включена минификация:

    console.log('There is Production mode');
    

    Это достаточно удобный функционал для того, чтобы разделять код на слои и делать продакшн-код ещё более чистым и быстрым.

  • BowerWebpackPlugin — сторонний плагин, который позволяет осуществить прозрачное подключение любых bower-пакетов.

    Установка:

    npm install bower-webpack-plugin --save-dev
    

    Настройка (build.js):

    ...
    	plugins: [
    		new BowerWebpackPlugin({
    			modulesDirectories: ['bower_components'],
    			manifestFiles: ['bower.json', '.bower.json'],
    			includes: /.*/,
    			excludes: /.*\.less$/
    		}),
    ...
    

    Использование:

    bower install jquery
    

    index.js:

    var $ = require('jquery');
    if (NODE_ENV === 'production') {
    	$('body').html('There is Production mode.');
    } else {
    	$('body').html('There is Development mode.');
    }
    

  • ExtractTextPlugin позволяет извлеч содержимое всех подключаемых CSS-файлов в один отдельный CSS-файл. Это позволяет ускорить загрузку, поскольку CSS загружается асинхронно (параллельно JS-файлам). Рекомендуется использовать при большом количестве стилей.

    Установка:

    npm install css-loader style-loader extract-text-webpack-plugin --save-dev
    

    Примечание: пакеты css-loader и style-loader — это загрузчики для загрузки и подключения в DOM стилей. Подробней о них речь пойдёт дальше.

    Настройка (build.js):

    ...
    	module: {
    		loaders: [
    			{
    				test: /\.css$/,
    				loader: ExtractTextPlugin.extract('style-loader', 'css-loader')
    			},
    ...
    		],
    	},
    	plugins: [
    		new ExtractTextPlugin('styles.css'),
    ...
    

    Использование:

    • src/header.css:

      h1 {
      	color: #036;
      }
      

    • src/header.js:

      var $ = require('jquery');
      require('./header.css');
      $('body').prepend('<h1>Hello, Habrahabr</h1>');
      

    • src/index.css:

      body {
      	background: #eee;
      }
      

    • src/index.js:

      var $ = require('jquery');
      require('./index.css');
      require('./header');
      if (NODE_ENV === 'production') {
      	$('body').append('There is Production mode.');
      } else {
      	$('body').append('There is Development mode.');
      }
      

    • index.html:

      <!doctype html>
      <html>
      <head>
      	<link rel="stylesheet" href="assets/styles.css" />
      </head>
      <body>
      	<script src="assets/bundle.js"></script>
      </body>
      </html>
      

Загрузчики


Благодаря этой точке расширения webpack обеспечивает прозрачное подключение любой статики — CSS, LESS, SASS, Stylus, CoffeeScript, JSX, JSON, шрифтов, графики, шаблонов и т.д. Вы просто указываете имя файла в require(), а загрузчики сами обеспечивают все необходимые операции для его подключения.

Подключаете CSS? Загрузчики позаботятся обо всём сами — загрузят CSS-данные, а в момент исполнения добавят в DOM элемент с этими стилями.

Пишете модули в LESS, CoffeeScript или JSX? Загрузчики сами выполнят весь пре-процессинг при сборке — Вам достаточно просто указать имя файла.

Пример использования загрузчиков

Установка:

npm install style-loader css-loader json-loader handlebars-loader url-loader --save-dev

Настройка (build.js):

...
	module: {
		loaders: [
			{test: /\.css$/, loader: 'style-loader!css-loader'},
			{test: /\.json$/, loader: 'json-loader'},
			{test: /\.hbs$/, loader: 'handlebars-loader'},
			{
				test: /\.(eot|woff|ttf|svg|png|jpg)$/,
				loader: 'url-loader?limit=30000&name=[name]-[hash].[ext]'
			},
...

Загрузчики указываются в порядке справа налево, т.е. для CSS — сначала используется css-loader, а его результат передаётся в style-loader, который помещает загруженные данные, как блок <style />.

url-loader — особенный загрузчик. В данном примере, если файлы графики и шрифтов имеют размер до 30кб, он вставляет их в виде data:uri. Если же они превышают этот объем, то он сохраняет их в выходную директорию с заданным шаблоном имени, где hash — уникальное значение для файла. Такой подход позволяет с одной стороны — избежать дополнительных обращений к серверу (даже при Keep-Alive, это дорогостоящая операция), с другой — избежать проблем с кэшированием одноимённых файлов (этот подход известен, как static freeze).

Использование:

  • src/customer.json:

    {"name": "Habrahabr"}
    

  • src/header.hbs:

    <h1>Hello, dear {{name}}</h1>
    

  • src/header.js:

    var $ = require('jquery');
    // загружаем данные из JSON-файла в объект:
    var customer = require('./customer.json');
    // загружаем и компилируем шаблон:
    var Header = require('./header.hbs');
    require('./header.css');
    // отдаём данные в шаблон и выводим полученный HTML
    $('body').prepend(Header(customer));
    

Интеграция с React JSX

webpack отлично дружит с React и позже станет ясно почему, а пока просто приведу пример подключения JSX-скриптов.

Установка:

npm install react jsx-loader --save-dev

Настройка (build.js):

...
	resolve: {
		extensions: ['', '.js', '.jsx'],
	},
	module: {
		loaders: [
			{test: /\.jsx$/, loader: 'jsx-loader'},
...

Использование:

  • src/toolbar.jsx:

    var React = require('react');
    module.exports = React.createClass({displayName: 'Toolbar',
    	render: function () {
    		return (
    			<div>
    				<button>Button 1</button>
    			</div>
    		);
    	}
    });
    

  • src/index.js:

    var $ = require('jquery');
    var React = require('react');
    var Toolbar = require('./toolbar');
    require('./index.css');
    require('./header');
    React.render(
    	React.createElement(Toolbar),
    	document.getElementById('toolbar')
    );
    if (NODE_ENV === 'production') {
    	$('body').append('There is Production mode.');
    } else {
    	$('body').append('There is Development mode.');
    }
    

  • index.html:

    <!doctype html>
    <html>
    <body>
    	<div id="toolbar"></div>
    	<script src="assets/bundle.js"></script>
    </body>
    </html>
    

Инструмент webpack-dev-server


Позволяет видеть обновления на странице без пересборки проекта. Легко, удобно и быстро.
Как это работает:

  1. создаётся веб-сервер на основе вашей assets-директории;
  2. при загрузке файла сборки, устанавливается соединение через socket.io;
  3. как только вы что-то изменили — автоматически обновляется открытая страница.

Запуск через консоль

npm install webpack-dev-server -g
webpack-dev-server --content-base assets/

Запуск через скрипт

Установка:

npm install webpack-dev-server --save-dev

Использование:

  1. Конфигурацию выносим в webpack.config.js, оставляя в builds.js лишь:
    var webpack = require('webpack');
    var config = require('./webpack.config');
    var compiler = webpack(config);
    compiler.run(function () {
    // stay silent
    });
    

  2. Создаём dev-server.js:

    var webpack = require('webpack');
    var WebpackDevServer = require('webpack-dev-server');
    var config = require('./webpack.config.js');
    var devServer = new WebpackDevServer(
    	webpack(config),
    	{
    		contentBase: __dirname,
    		publicPath: '/assets/'
    	}
    ).listen(8088, 'localhost');
    

  3. Запускаем:

    node dev-server
    

  4. Открываем: http://localhost:8088/webpack-dev-server/

    Перед нами появится index.html со строкой статуса в шапке: “App ready”. Если сейчас мы что-то изменим в коде, страница автоматически обновится с изменениями.

Hot Module Replacement — чистая магия


Позволяет обновлять, удалять и добавлять модули в реальном режиме, т.е. даже без перезагрузки страницы (тем самым сохранив её состояние). Мало того, что это безумно весело, это позволяет на порядок быстрей прототипировать веб-приложения и разрабатывать сложные Single Page Applications.

Развёрнутый ответ автора на вопрос What exactly is Hot Module Replacement in Webpack?

Как это работает в связке с React:

  1. Вы открываете на одном мониторе — IDE, на втором — браузер.
  2. В окне IDE изменяете код своего React-компонента, сохраняете.
  3. В это время на страницу через открытое socket-соединение передаётся информация только об изменённой части.
  4. Происходит “горячая” замена компонента (unmount + mount).
  5. На экране автоматические обновляется изменённый компонент.

Подробней об этом можно почитать на странице разработчика расширения.
Или посмотреть на этом видео:



Невероятно, ведь так?

Chunks


webpack позволяет разбивать собранный код на части. Например, Вы можете выделить общий код для всех страниц в assets/common.js, а для каждой отдельной страницы делать свой assets/feed.js, assets/products.js и т.д. Таким образом, при первой загрузке, common.js будет закеширован, а для каждой из страниц Вашего проекта будет достаточно догрузить небольшой файл с нужным для неё чанком. Это позволит существенно ускорить загрузку страниц.
Забегая вперёд, Facebook использует порядка 50 чанков на странице выдачи, в то время, как Instagram в среднем по два, например — common.js и Feed.js.

Производительность и анализ


По моим личным наблюдениям и наблюдениям коллег производительность сборки у webpack на порядок выше аналогов. Во многом за счёт применения “умной” сборки и AST-парсинга.

Для тонкой и более эффективной оптимизации webpack предлагает развитую статистику по результату сборки Вашего проекта и инструменты для визуального анализа.

Подведём итоги


Итак, мы рассмотрели:

  • Быстрый старт
  • Плагины и их примеры:
    • webpack.optimize.UglifyJsPlugin
    • webpack.optimize.DedupePlugin
    • webpack.DefinePlugin
    • BowerWebpackPlugin
    • ExtractTextPlugin
  • Загрузчики:
    • Работа со статикой
    • Подключение React JSX
  • webpack-dev-server
  • Hot Module Replacement
  • Chunks
  • Производительность и анализ

Миграция со старых сборщиков


Помимо CommonJS, из коробки поддерживается и AMD — это позволяет быстро и безболезненно перебраться с Require.js.
Миграция с Browserify происходит также легко и волшебно, как и всё остальное — для этого в документации даже есть раздел webpack for Browserify users.

Как насчёт поддержки?


По личному опыту — на вопросы в github ответили в течении дня. Разработчики очень открытые и активные. Делал pull-request'ы — автор принял их на следующий день. Динамика коммитов на github впечатляет.

Так значит можно доверять?


Безусловно. Например, команда Facebook использует webpack для веб-интерфейса Instagram. Если быть честным, то делая реверс-инжиниринг этого проекта я и наткнулся на webpack.

Кроме этого, Twitter использует webpack для своих проектов, о чём на конференции Fronteers 2014 рассказал Nicholas Gallagher.

Резюме


  1. Современный мир веб-разработки открывает перед нами, как невероятные возможности, так и проблемы.
  2. Основная проблема — постоянная эволюция (рост количества и качества как решений, так и проектов).
  3. Это ставит перед нами задачи — быть гибкими, открытыми, быстрыми и эффективными.
  4. Изолированные модули и единый интерфейс их взаимодействия — это то, без чего невозможно развитие и то, что делает из JavaScript полноценную экосистему.
  5. CommonJS стал стандартом де-факто в организации модулей (npm, Bower).
  6. На сегодняшний день, webpack — самая мощная платформа для сборки и оптимизации, которая учитывает весь опыт предыдущего поколения сборщиков (Require.js, Browserify) и реализует его наиболее эффективным способом. webpack может легко работать как с таскерами вроде Grunt и gulp, так и во многих случаях заменить их.
  7. webpack открывает перед нами мир npm (112 393 пакетов) и bower (20 694 пакетов), делая их использование таким же простым и прозрачным, как и использование своих модулей.

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

Ссылки


Документация по webpack — http://webpack.github.io/docs/
Скачать и попробовать — https://github.com/webpack/webpack
Пример из статьи — https://github.com/DenisIzmaylov/hh-webpack
Денис Измайлов @DenisIzmaylov
карма
14,0
рейтинг 0,0
Startup Makers: React, Relay, React Native, DevOps
Похожие публикации
Самое читаемое Разработка

Комментарии (13)

  • +1
    Простите, но плагин для bower вроде как не нужен, webpack умеет делать это из коробки github.com/xgrommx/angular-vk-app/blob/master/gulpfile.js#L40
    • 0
      Всё верно, я тоже использовал изначально встроенный ResolverPlugin, пока не столкнулся с проблемой.
      Возьмём пример по этой ссылке:
      ...
                  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.
  • 0
    Упоминалось, что Webpack лучше аналогов, в частности Browserify. Можно подробнее, чем именно он лучше?

    Вот, например, есть у Browserify возможность указывать в package.json поле browser, в котором можно подменять некоторые модули их браузерными версиями, что часто используется в изоморфных пакетах и фреймворках, не нашел ничего подобного у Webpack. Поэтому для меня Webpack всегда имел больше недостатков, чем преимуществ.

    Еще было упомянуто, что «По моим личным наблюдениям и наблюдением коллег производительность сборки у webpack на порядок выше аналогов», где можно посмотреть результаты исследования/тестирования производительности? Просто уж очень сомнительно, что Webpack может быть быстрее в 10 раз чем Browserify последней версии.
    • +1
      browserify беднее по функциональности и рантайм у него сильно больше. Подмену модулей, кажется, можно осуществить loader'ами.
  • 0
    Недавно перешел с browserify на webpack. Hot module replacement очень радует. В остальном, в моём случае, разницы особо нету. А, ну еще, gulp выпилился за ненадобностью.

    Посмотрел на webpack как раз после доклада moscowjs.
  • 0
    Есть несколько моментов, которые меня сильно смущают:
    1. entry-point почему-то является одним файлом. Причём, на сколько я понял, js-файлом. Хотелось бы указывать папку.
    2. Если я подключаю скрипт из модуля, то ожидаю, что подключится и css и прочие файлы. Но на сколько я понял, каждый файл должен быть достижим через ссылки из других фалов. Это ворох копипасты.
    3. К js безусловно добавляется webpack бутстрап, даже если он там не нужен (не используется require, например).

    Буду рад, если скажете, что я ошибаюсь по всем трём пунктам :-)
    • 0
      1. Это с одной стороны непривычно и кажется глупым, особенно для пользователей concat решений (например Sprockets). Но на деле вы явно строите дерево зависимостей начиная от вершины-entry и это очень упрощяет работу с большими проектами а так же ускоряет вход новых людей тк всегда и без проблем можно понять как работает приложение. Но если вам нужно просто взять и включить содержимое определенной папки — webpack это позволяет с помощью контекстов.

      2. Это очень просто реализуется с помощью webpack, можете посмотреть как мы это решили для своего проекта: component-resolver-webpack & component-css-loader.

      3. Бутстрап webpack — необходимое зло, но зло небольшое:
      243b + 20b per module + 4b per dependency

      Источник

      Важно понимать что это не просто concat утилита, а очень мощный менеджер зависимостей который многие вещи делает проще, но тем не менее требует инвестиций. Если вы не знаете зачем вам модульность, то вполне вероятно вам и не нужен webpack.
      • 0
        1. Что мешает директории быть этой самой вершиной entry? Или, на худой конец, какому-нибудь ini-файлу? И вообще, я хочу иметь возможность любой модуль со всеми его файлами оформить в виде независимой библиотеки. То есть чтобы подключились все файлы модуля и все необходимые им зависимости.
        require("./template/" + name + ".jade");
        

        Это какая-то чёрная магия. Я хочу простую вещь — чтобы модуль подключался целиком или же не подключался вовсе. Без шаманств.

        2. Довольно костыльное решение
        component-css-loader modifies original component source code and adds require('component_name.styl') at the first line.

        Бывает много скриптов и мало стилей или много стилей но мало скриптов или и стилей и скриптов мало, зато много шаблонов. Привязка к именам файлов ни к чему хорошему в этих случаях не приведёт.

        3. От чего же необходимое? Если используются рантайм фичи вебпака — безусловно. Но если не используются — зачем их пихать? На мой взгляд стоит разделить проект на:
        а) собственно сборщик, который собирает исходники
        б) рантайм библиотека, как один из исходников, которая подключается как и все остальные исходники — по наличию зависимости.

        И да, я знаю зачем мне модули
        • 0
          1. Да, без проблем. Но если в директорию вы решите поместить readme-файл? А если тесты для него? Как это исключать? Действительно логичней и чище было бы декомпозировать, исходя из того, что есть модуль, в котором указаны его основные зависимости. У тех в свою очередь могут быть другие. Например:
          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-запрос к отдельному загрузчику можем больше потерять.
          • 0
            Когда я смотрел его пол года назад он добавлял куда больше 243 байт мусора. Думаю мне стоит сделать второй подход к с наряду. Может удастся допилить до юзабельного состояния.

            > Но если в директорию вы решите поместить readme-файл? А если тесты для него? Как это исключать?

            Очень просто — правильно именуя файлы. Например:
            request.env=node.js — реализация для ноды
            request.env=web.js — реализация для браузера
            request.stage=test.js — универсальные тесты
            • 0
              Опять же, имеется ввиду сборка для продакшн = после минимизации.
              «Правильно» — это очень относительно, у каждого ведь своё «правильно». У меня оно немного другое. Не лучше, не хуже — просто другое. Поэтому тут было бы удобней сделать плагином, они как раз для таких случаев предназначены. Это действительно просто.
          • 0
            webpack и кофе готовит :) github.com/webpack/coffee-loader
  • 0
    Здесь был комментарий, который я перенёс выше. Не нашёл кнопки удаления.

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