Переход от Gulp к Webpack
Мой первый вопрос о том, как рекомендуется этот переключатель для простых проектов, только для предварительного процесса /Concat/Minify?
Понимание этих будущих "стандартов", таких как Webpack вместе с PostCss-NextCss-Autoprefixer и т.д., похоже на то, что меня преследует....
Итак, это приводит к моему следующему вопросу: есть ли какой-либо учебник, который будет посвящен простым задачам, таким как тот, который я сказал в своем первом вопросе?
Или это простой способ изменить мой gulpfile.js
на webpack-config.js
Мои обычные задачи в gulp - это не лучшие практики, но хорошо работают:
//load plugins
var gulp = require('gulp'),
runSequence = require('run-sequence'),
sass = require('gulp-ruby-sass'),
compass = require('gulp-compass'),
rev = require('gulp-rev'),
revDel = require('rev-del'),
del = require('del'),
minifycss = require('gulp-minify-css'),
uglify = require('gulp-uglify'),
rename = require('gulp-rename'),
concat = require('gulp-concat'),
notify = require('gulp-notify'),
plumber = require('gulp-plumber'),
watch = require('gulp-watch'),
path = require('path');
//the title and icon that will be used for the Grunt notifications
var notifyInfo = {
title: 'Gulp',
icon: path.join(__dirname, 'gulp.png')
};
//error notification settings for plumber
var plumberErrorHandler = { errorHandler: notify.onError({
title: notifyInfo.title,
icon: notifyInfo.icon,
message: "Error: <%= error.message %>"
})
};
//patches
var paths = {
scriptsAbs : '_coffeescript/',
stylesAbs: '_scss/',
scriptsCom : '_coffeescript/' + '**/*.js',
stylesCom :'_scss/' + '**/*.scss',
cssCom : 'resources/css',
jsCom : 'resources/js',
imgCom : 'resources/img'
};
gulp.task('clean',
function (cb) {
del([
paths.cssCom + '/*',
paths.jsCom + '/*'
], cb);
});
//styles
gulp.task('styles',
function() {
return gulp.src(paths.stylesCom)
.pipe(plumber(plumberErrorHandler))
.pipe(compass({
sass: '_scss',
css: paths.cssCom,
image: paths.imgCom,
style: 'expanded',
relative: true,
require: ['normalize-scss', 'susy']
}))
.pipe(gulp.dest(paths.cssCom))
.pipe(rename({ suffix: '.min' }))
.pipe(minifycss())
.pipe(gulp.dest(paths.cssCom))
.pipe(rev())
.pipe(gulp.dest(paths.cssCom))
.pipe(rev.manifest())
.pipe(revDel({ dest: paths.cssCom }))
.pipe(gulp.dest(paths.cssCom))
.pipe(notify({ message: 'Styles task completed' }))
});
//scripts
gulp.task('scripts',
function() {
return gulp.src(paths.scriptsCom)
.pipe(plumber(plumberErrorHandler))
.pipe(concat('main.js'))
.pipe(gulp.dest(paths.jsCom))
.pipe(rename({ suffix: '.min' }))
.pipe(uglify())
.pipe(gulp.dest(paths.jsCom))
.pipe(rev())
.pipe(gulp.dest(paths.jsCom))
.pipe(rev.manifest())
.pipe(revDel({ dest: paths.jsCom }))
.pipe(gulp.dest(paths.jsCom))
.pipe(notify({ message: 'Scripts Concatenated completed' }))
// .pipe(reload({stream:true}));
});
gulp.task('default', ['clean','styles','scripts'], function(){
gulp.watch(paths.stylesCom, ['styles'])
gulp.watch(paths.scriptsCom, ['scripts'])
//watch .php files
// gulp.watch(['*.php'], ['bs-reload'])
});
И я начинаю использовать postcss, который делает мой рабочий процесс, мм, лучше... иногда.
Что вы думаете обо всем этом? Где начинается правильный путь?
EDIT//28 июня 2017 года
В этот день наш прогресс с Webpack 1 был супер удовлетворительным и успешным, наш рабочий процесс намного быстрее, и наша зависимость в этом инструменте неизменна.
Это webpack.config.js
, который мы используем каждый день:
"use strict";
var webpack = require('webpack');
var glob = require('glob-all');
var ExtractTextPlugin = require("extract-text-webpack-plugin");
var BrowserSyncPlugin = require('browser-sync-webpack-plugin');
let start = {
entry: {
scripts: glob.sync(
[
'./_javascript/*.js',
'./_cssnext/*.pcss'
]
)},
output: {
path: './resources/js',
filename: 'bundle--[name].js'
},
watchOptions: {
poll: true
},
postcss: function (webpack) {
return [
require("postcss-import")({addDependencyTo: webpack}),
require("postcss-url")(),
require("precss")(),
require("postcss-cssnext")(),
require('postcss-font-magician')(),
require("postcss-reporter")(),
require("postcss-browser-reporter")(),
require('postcss-inline-svg')(),
require('postcss-urlrev')(),
require('postcss-fontpath')(),
require('postcss-object-fit-images')()
]
},
module: {
loaders: [
{
test: /\.jsx?$/,
loader: 'babel-loader'
},
{
test: /\.p?css$/,
loader: ExtractTextPlugin.extract(
'style-loader',
'css-loader!postcss-loader'
)
}
]
},
plugins: [
new webpack.optimize.CommonsChunkPlugin({name: 'scripts', filename: 'bundle--[name].js'}),
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false
}
}),
new ExtractTextPlugin("../css/bundle--styles.css"),
new BrowserSyncPlugin({
host: 'localhost',
port: 3000,
proxy: 'localhost:8002',
browser: 'google chrome',
ghostMode: false
})
]
};
module.exports = start;
Но времена изменились и пришло время перейти на Webpack 3, и теперь мы находимся в процессе изменения этого webpack.config.js
до версии 3
ОБНОВЛЕНИЕ 24.07.17 || v1 (Tryout 10000.1)
[Переместить с Webpack 1 на Webpack 2/3]
Ответы
Ответ 1
Хорошо, я получаю отличные результаты благодаря этому мультфильму:
https://www.phase2technology.com/blog/bundle-your-front-end-with-webpack/
Мой первый подход заключается в следующем:
webpack-config.js
'use strict';
const webpack = require('webpack'),
path = require('path'),
autoprefixer = require('autoprefixer'),
glob = require('glob');
let script = {
entry: {
'scripts': glob.sync('./_javascript/*.js'),
},
module: {
loaders: [
// Javascript: js, jsx
{
test: /\.jsx?$/,
loader: 'babel-loader'
},
// CSS: scss, css
{
test: /\.s?css$/,
loaders: ['style', 'css', 'sass', 'postcss-loader']
},
// SVGs: svg, svg?something
{
test: /\.svg(\?.*$|$)/,
loader: 'file-loader?name=/img/[name].[ext]'
},
// Images: png, gif, jpg, jpeg
{
test: /\.(png|gif|jpe?g)$/,
loader: 'file?name=/img/[name].[ext]'
},
// HTML: htm, html
{
test: /\.html?$/,
loader: "file?name=[name].[ext]"
},
// Font files: eot, ttf, woff, woff2
{
test: /\.(eot|ttf|woff2?)(\?.*$|$)/,
loader: 'file?name=/fonts/[name].[ext]'
}
]
},
output: {
path: './resources/js',
filename: 'bundle--[name].js'
},
plugins: [
new webpack.optimize.CommonsChunkPlugin(['scripts'], 'bundle--[name].js'),
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false
}
})
]
};
let style = {
entry: {
'styles': glob.sync('./_nextcss/*.css'),
},
module: {
loaders: [
{
test: /\.s?css$/,
loaders: ['style', 'css', 'sass', 'postcss-loader']
},
]
},
postcss: function (webpack) {
return [
require("postcss-import")({
addDependencyTo: webpack
}),
require("postcss-url")(),
require("postcss-cssnext")(),
require("postcss-browser-reporter")(),
require("postcss-reporter")(),
]
},
output: {
path: './resources/css',
filename: 'bundle--[name].css'
},
};
module.exports = [
script,
style,
];
Это создает bundle--script.js
успешно, но у меня возникают некоторые проблемы с частью css.
Он не будет предварительно обрабатывать что-либо:/
Я буду обновлять здесь, если я доработаю это, тем временем, я буду очень благодарен, если кто-то может мне помочь.
Ответ 2
Для простых проектов я бы не рекомендовал коммутатор вообще. В конце концов, это мой личный вкус, и я предпочитаю постобработку через легко понятный javascript (gulp).
Как вы сказали в своем вопросе, ваша текущая настройка работает хорошо: зачем зачем исправлять что-то, что не сломалось? Я бы сосредоточился на рефакторинг вашего кода gulp, чтобы сделать его более читаемым, разделил длинные функции на меньшие задачи gulp.
В конце концов, использование webpack требует изучения множества специфических параметров конфигурации, связанных с webpack, в то время как gulp вы в основном просто пишите команды vanilla js.
Ответ 3
Я не думаю, что вам нужен загрузчик postcss. Я имею в виду, пока. Вы просто переходите от одного к инструменту к другому, так что вам нужно как можно меньше наклоняться.
{
test: /(\.css|\.scss)$/,
include: path.join(__dirname, 'src'),
loaders: ['style-loader', 'css-loader', 'sass-loader']
}
Помните, что include
внутри моего кода зависит от вашей конфигурации. После этого я решил бы избавиться от "относительного" пути, который у вас есть в gulp. Это может сломать ваши вещи, если вы хотите поддерживать среду development
и production
. Просто личный опыт.
Ответ 4
Понятия Gulp и Webpack совершенно разные: вы сообщаете Gulp, как поэтапно поместить интерфейсный код вместе, но вы скажете Webpack, что хотите, через файл конфигурации. Таким образом, если вы переключаетесь, нет простого сопоставления "один-к-одному".
Наша компания переехала из Gulp в Webpack в прошлом году. Я обнаружил, что понимание различий двух инструментов очень полезно для перехода. Вот короткая статья (5 минут). Я написал объяснение изменения мышления: https://medium.com/@Maokai/compile-the-front-end-from-gulp-to-webpack-c45671ad87fe
Хотя наш переход занял некоторое время, мы выяснили, как переместить все, что мы сделали в Gulp, в Webpack. Таким образом, для нас все, что мы делали в Gulp, мы также можем делать через Webpack, но не наоборот.