Комментарии 11
Хорошая идея про модульное оформление, гораздо лучше читается, но зачем вы используете второй аргумент argv для определения окружения? Официальная документация рекомендует использовать параметр env.
Обратите внимание на пути:
PATHS.source + '/pages/index/index.pug'
Под Windows такого вида unix-пути не заработают.
Правильнее писать так:
const path = require('path');
const merge = require('webpack-merge');
const pug = require('./webpack/pug');
const common = merge([
{
entry: {
'index': path.join(PATHS.source,'pages','index','index.pug'),
'blog': path.join(PATHS.source,'pages','blog','blog.js'),
},
output: {
path: PATHS.build,
filename: path.join('.','js','[name].js'),
},
plugins: […],
optimization: { … },
},
pug(),
]);
P.S. Забавно, ровно то же самое, что и в топике, пилил для своей фирмы еще летом — тогда, по иронии, материала было «кот наплакал» и мигрировать v2->v4 было больно.
UPD:
test: require.resolve('jquery'),
use: [{
loader: 'expose-loader',
options: 'jQuery'
},{
loader: 'expose-loader',
options: '$'
}]
А в packaje.json прописать что-то такое
«expose-loader»: "^0.7.5",
И вот уже теперь можно будет в консольке написать просто знак $, и jQ нормально будет доступен.
Вы можете спросить «а зачем это надо?», на что сразу отвечу — когда вы подключаете какой-либо плагин jQ вне сборщика, то он не будет иметь доступа до библиотеки при использовании ProvidePlugin.
UPD2: Да и hot-reload неплохо было бы использовать (флаг -w в npm-конфиге)… еще стоило бы прикрутить кеширование (хотя бы в один уровень) — скорость сборки бандлов можно снизить в несколько раз.
не посчитал нужным использовать тут
он приложен как хороший
не для себя, а для общего пользования
Это взаимо-противоречие.
Если вы делаете обучающий материал, то он не должен в себе содержать неправильного/ошибок.
А у вас они есть! Вы исходно предоставляете не правильный вариант — в этом смысл. И вам делают подсказки люди, у которых больше знаний/опыта. Зачем упорно гнуть свою линию (что материал не «об этом»)?
Лучше бы внесли исправления в репозиторий — это ведь по сути универсальные аспекты, без разницы «какой там проект» (иначе вообще тот же jQ и в вашем материале лишний — у людей его может и не быть,… а раз уж вы его подключили, то подключайте верным образом) :)
Ровно то же самое касается и «путей» — без разницы, что у вас Win10 (у меня так же, к слову). Важно писать универсальный вариант, с «правильными» путями.
P.S. Да и в целом — «вселенная node.js» не мой дом родной, я из Java-world, тем не менее… :)
Скажите, что неправильного в игнорировании path.join
в пользу обычной конкатенации unix-like. Насколько я понимаю, проблемы могут возникнуть:
- при вызове spawn, exec и пр. внешние запуски других приложений
- хитрые махинации с частями путей, полученными из разных источников
Я ничего не упустил? Суть именно во втором пункте? Что-то вроде складывания C:\somepath
и otherpath/file.txt
?
P.S. вообще не использую path.join
(каюсь, грешен), т.к. давным давно не видел Windows на машинах разработчиков, и сам не использую. Хочу понять насколько проблема реально актуальна.
Я ничего не упустил? Суть именно во втором пункте? Что-то вроде складывания C:\somepath и otherpath/file.txt?
Вот конкретно подобное у нас таки «сплошь и рядом» (в основном из-за того, что разные задачи требуют разные суб-инструменты, где бывают предпочтительными разные виды слешей,… ага, как раз тоже «не заморачивались универсальностью»).
За остальное не скажу, лишь, если говорить конкретно о путях, то, что когда сам писал с большей платформо-зависимостью, мне сразу «по рукам стучали» (ибо нефиг привыкать писать «тяп-ляп», лучше один раз написать «как надо» и чтобы потом работало N-лет всегда, надежным образом — и так существует множество ситуаций, когда приходится намеренно писать «плохой код», так зачем это делать еще и, когда можно без этого?).
*у нас судя по всему практически все (за исключением пары машин (одна из которых сервак) — все на Win). У знакомых, в фирмах размера ~>100ч., аналогично — всюду Win. При том, что мизерный процент чего-либо таки на Unix.
Но автор считает это «не нужным», не смотря на
интересных решениях, которые помогут вам быстрее собрать сборку
При этом материал нужен как раз новичкам в мире node/npm/webpack — тем самым людям, которые еще не умеют отличать хорошего от плохого.
UPD: посмотрел быстро поиском по проекту — да, кое-где идет вызов посредством командной строки из php в java (угу, и такой лес присутствует).
https://github.com/andywer/webpack-blocks не то же самое ли делает?
Webpack 4 и разделение конфигурационного файла на модули