Gulp + Webpack или ПРОСТО Webpack?

Я вижу людей, использующих gulp с webpack. Но тогда я читаю webpack может заменить глоток? Я полностью запутался здесь ... кто-то может объяснить?

ОБНОВИТЬ

в конце я начал с глотком. Я был новичком в современном интерфейсе и просто хотел быстро начать работу. Теперь, когда у меня уже достаточно года мокрые ноги, я готов перейти к веб-упаковке. Я предлагаю тот же маршрут для людей, которые начинают в той же обуви. Не говоря, что вы не можете попробовать веб-пакет, а просто говорите, если вам кажется, что сначала сложно начать с глотка ... в этом нет ничего плохого.

Если вы не хотите глотать, да, есть хрюканье, но вы также можете просто указать команды в вашем package.json и вызывать их из командной строки без запуска задач, чтобы просто начать работу. Например:

"scripts": {
      "babel": "babel src -d build",
      "browserify": "browserify build/client/app.js -o dist/client/scripts/app.bundle.js",
      "build": "npm run clean && npm run babel && npm run prepare && npm run browserify",
      "clean": "rm -rf build && rm -rf dist",
      "copy:server": "cp build/server.js dist/server.js",
      "copy:index": "cp src/client/index.html dist/client/index.html",
      "copy": "npm run copy:server && npm run copy:index",
      "prepare": "mkdir -p dist/client/scripts/ && npm run copy",
      "start": "node dist/server"
    },

Этот ответ может помочь. Runner (Gulp, Grunt и т. Д.) И Bundlers (Webpack, Browserify). Зачем использовать вместе?

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

var gulp = require('gulp');
var webpack = require('webpack');
var gutil = require('gutil');
var babel = require('babel/register');
var config = require(path.join('../..', 'webpack.config.es6.js'));

gulp.task('webpack-es6-test', function(done){
   webpack(config).run(onBuild(done));
});

function onBuild(done) {
    return function(err, stats) {
        if (err) {
            gutil.log('Error', err);
            if (done) {
                done();
            }
        } else {
            Object.keys(stats.compilation.assets).forEach(function(key) {
                gutil.log('Webpack: output ', gutil.colors.green(key));
            });
            gutil.log('Webpack: ', gutil.colors.blue('finished ', stats.compilation.name));
            if (done) {
                done();
            }
        }
    }
}

Я думаю, вы обнаружите, что, поскольку ваше приложение усложняется, вы можете захотеть использовать gulp с задачей webpack, как в примере выше. Это позволяет вам делать еще несколько интересных вещей в вашей сборке, чего действительно не делают загрузчики и плагины веб-пакетов, т.е. создание выходных каталогов, запуск серверов и т. д. Если быть кратким, веб-пакет на самом деле может делать эти вещи, но вы можете счесть их ограниченными для ваших долгосрочных потребностей. Одним из самых больших преимуществ, которые вы получаете от gulp -> webpack, является то, что вы можете настроить конфигурацию webpack для различных сред и заставить gulp выполнить правильную задачу в нужное время. Это действительно ваше дело, но нет ничего плохого в запуске webpack из gulp, на самом деле есть несколько довольно интересных примеров того, как это сделать.,

Сценарии NPM могут делать то же самое, что и gulp, но примерно в 50 раз меньше кода. Фактически, без кода, только аргументы командной строки.

Например, описанный вами вариант использования, в котором вы хотите иметь разный код для разных сред.

С Webpack + NPM Scripts это так просто:

"prebuild:dev": "npm run clean:wwwroot",
"build:dev": "cross-env NODE_ENV=development webpack --config config/webpack.development.js --hot --profile --progress --colors --display-cached",
"postbuild:dev": "npm run copy:index.html && npm run rename:index.html",

"prebuild:production": "npm run clean:wwwroot",
"build:production": "cross-env NODE_ENV=production webpack --config config/webpack.production.js --profile --progress --colors --display-cached --bail",
"postbuild:production": "npm run copy:index.html && npm run rename:index.html",

"clean:wwwroot": "rimraf -- wwwroot/*",
"copy:index.html": "ncp wwwroot/index.html Views/Shared",
"rename:index.html": "cd ../PowerShell && elevate.exe -c renamer --find \"index.html\" --replace \"_Layout.cshtml\" \"../MyProject/Views/Shared/*\"",

Теперь вы просто поддерживаете два сценария конфигурации веб-пакета, один для режима разработки webpack.development.jsи один для рабочего режима webpack.production.js. Я также использую webpack.common.jsконфигурацию webpack, которая используется во всех средах, и использую webpackMerge для их объединения.

Из-за крутости сценариев NPM он позволяет легко создавать цепочки, подобно тому, как gulp использует Streams / pipe.

В приведенном выше примере, чтобы построить для разработки, вы просто перейдете к командной строке и выполните npm run build:dev.

1. NPM сначала запустится prebuild:dev,
2. Тогда build:dev,
3. И наконец postbuild:dev.

preИ postпрефиксы сказать НПМ , которые для того , чтобы выполнить в.

Если вы заметили, что с помощью скриптов Webpack + NPM вы можете запускать нативные программы, например rimraf, вместо gulp-wrapper для нативной программы, такой как gulp-rimraf. Вы также можете запускать собственные файлы Windows .exe, как я это делал здесь, elevate.exeили собственные файлы * nix в Linux или Mac.

Попробуйте сделать то же самое с глотком. Вам придется подождать, пока кто-нибудь придет и напишет gulp-wrapper для нативной программы, которую вы хотите использовать. Кроме того, вам, вероятно, понадобится написать сложный код, подобный следующему: (взят прямо из репозитория angular2-seed )

Код разработки Gulp

import * as gulp from 'gulp';
import * as gulpLoadPlugins from 'gulp-load-plugins';
import * as merge from 'merge-stream';
import * as util from 'gulp-util';
import { join/*, sep, relative*/ } from 'path';

import { APP_DEST, APP_SRC, /*PROJECT_ROOT, */TOOLS_DIR, TYPED_COMPILE_INTERVAL } from '../../config';
import { makeTsProject, templateLocals } from '../../utils';

const plugins = <any>gulpLoadPlugins();

let typedBuildCounter = TYPED_COMPILE_INTERVAL; // Always start with the typed build.

/**
 * Executes the build process, transpiling the TypeScript files (except the spec and e2e-spec files) for the development
 * environment.
 */
export = () => {
  let tsProject: any;
  let typings = gulp.src([
    'typings/index.d.ts',
    TOOLS_DIR + '/manual_typings/**/*.d.ts'
  ]);
  let src = [
    join(APP_SRC, '**/*.ts'),
    '!' + join(APP_SRC, '**/*.spec.ts'),
    '!' + join(APP_SRC, '**/*.e2e-spec.ts')
  ];

  let projectFiles = gulp.src(src);
  let result: any;
  let isFullCompile = true;

  // Only do a typed build every X builds, otherwise do a typeless build to speed things up
  if (typedBuildCounter < TYPED_COMPILE_INTERVAL) {
    isFullCompile = false;
    tsProject = makeTsProject({isolatedModules: true});
    projectFiles = projectFiles.pipe(plugins.cached());
    util.log('Performing typeless TypeScript compile.');
  } else {
    tsProject = makeTsProject();
    projectFiles = merge(typings, projectFiles);
  }

  result = projectFiles
    .pipe(plugins.plumber())
    .pipe(plugins.sourcemaps.init())
    .pipe(plugins.typescript(tsProject))
    .on('error', () => {
      typedBuildCounter = TYPED_COMPILE_INTERVAL;
    });

  if (isFullCompile) {
    typedBuildCounter = 0;
  } else {
    typedBuildCounter++;
  }

  return result.js
    .pipe(plugins.sourcemaps.write())
// Use for debugging with Webstorm/IntelliJ
// https://github.com/mgechev/angular2-seed/issues/1220
//    .pipe(plugins.sourcemaps.write('.', {
//      includeContent: false,
//      sourceRoot: (file: any) =>
//        relative(file.path, PROJECT_ROOT + '/' + APP_SRC).replace(sep, '/') + '/' + APP_SRC
//    }))
    .pipe(plugins.template(templateLocals()))
    .pipe(gulp.dest(APP_DEST));
};

Код производства Gulp

import * as gulp from 'gulp';
import * as gulpLoadPlugins from 'gulp-load-plugins';
import { join } from 'path';

import { TMP_DIR, TOOLS_DIR } from '../../config';
import { makeTsProject, templateLocals } from '../../utils';

const plugins = <any>gulpLoadPlugins();

const INLINE_OPTIONS = {
  base: TMP_DIR,
  useRelativePaths: true,
  removeLineBreaks: true
};

/**
 * Executes the build process, transpiling the TypeScript files for the production environment.
 */

export = () => {
  let tsProject = makeTsProject();
  let src = [
    'typings/index.d.ts',
    TOOLS_DIR + '/manual_typings/**/*.d.ts',
    join(TMP_DIR, '**/*.ts')
  ];
  let result = gulp.src(src)
    .pipe(plugins.plumber())
    .pipe(plugins.inlineNg2Template(INLINE_OPTIONS))
    .pipe(plugins.typescript(tsProject))
    .once('error', function () {
      this.once('finish', () => process.exit(1));
    });


  return result.js
    .pipe(plugins.template(templateLocals()))
    .pipe(gulp.dest(TMP_DIR));
};

Фактический код залпа гораздо сложнее, поскольку это только 2 из нескольких десятков файлов залога в репо.

Итак, какой из них вам легче?

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

ОБНОВИТЬ

Я столкнулся с одним сценарием, в котором я хотел использовать Gulp в сочетании со скриптами NPM и Webpack.

Когда мне нужно выполнить удаленную отладку, например, на устройстве iPad или Android, мне нужно запустить дополнительные серверы. В прошлом я запускал все серверы как отдельные процессы из IntelliJ IDEA (или Webstorm), что легко с «сложной» конфигурацией выполнения. Но если мне нужно остановить и перезапустить их, было утомительно закрывать 5 разных вкладок сервера, плюс вывод распределялся по разным окнам.

Одним из преимуществ gulp является то, что он может объединять весь вывод отдельных независимых процессов в одно консольное окно, которое становится родительским для всех дочерних серверов.

Поэтому я создал очень простую задачу gulp, которая просто запускает мои сценарии NPM или команды напрямую, поэтому весь вывод отображается в одном окне, и я могу легко завершить все 5 серверов одновременно, закрыв окно задачи gulp.

Gulp.js

/**
 * Gulp / Node utilities
 */
var gulp = require('gulp-help')(require('gulp'));
var utils = require('gulp-util');
var log = utils.log;
var con = utils.colors;

/**
 * Basic workflow plugins
 */
var shell = require('gulp-shell'); // run command line from shell
var browserSync = require('browser-sync');

/**
 * Performance testing plugins
 */
var ngrok = require('ngrok');

// Variables
var serverToProxy1 = "localhost:5000";
var finalPort1 = 8000;


// When the user enters "gulp" on the command line, the default task will automatically be called. This default task below, will run all other tasks automatically.

// Default task
gulp.task('default', function (cb) {
   console.log('Starting dev servers!...');
   gulp.start(
      'devserver:jit',
      'nodemon',
      'browsersync',
      'ios_webkit_debug_proxy'
      'ngrok-url',
      // 'vorlon',
      // 'remotedebug_ios_webkit_adapter'
   );
});

gulp.task('nodemon', shell.task('cd ../backend-nodejs && npm run nodemon'));
gulp.task('devserver:jit', shell.task('npm run devserver:jit'));
gulp.task('ios_webkit_debug_proxy', shell.task('npm run ios-webkit-debug-proxy'));
gulp.task('browsersync', shell.task(`browser-sync start --proxy ${serverToProxy1} --port ${finalPort1} --no-open`));
gulp.task('ngrok-url', function (cb) {
   return ngrok.connect(finalPort1, function (err, url) {
      site = url;
      log(con.cyan('ngrok'), '- serving your site from', con.yellow(site));
      cb();
   });
});
// gulp.task('vorlon', shell.task('vorlon'));
// gulp.task('remotedebug_ios_webkit_adapter', shell.task('remotedebug_ios_webkit_adapter'));

На мой взгляд, все еще достаточно кода для запуска 5 задач, но он работает для этой цели. Один caveate является то , что , gulp-shellкажется, не запускать некоторые команды правильно, например ios-webkit-debug-proxy. Поэтому мне пришлось создать сценарий NPM, который просто выполняет ту же команду, и затем он работает.

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

ОБНОВЛЕНИЕ 2

Теперь я использую скрипт, который вызывается одновременно, который выполняет ту же функцию, что и описанная выше задача gulp. Он запускает несколько сценариев CLI параллельно и направляет их все в одно и то же окно консоли, и его очень просто использовать. Еще раз, код не требуется (ну, код находится внутри node_module для одновременного использования, но вам не нужно беспокоиться об этом)

// NOTE: If you need to run a command with spaces in it, you need to use 
// double quotes, and they must be escaped (at least on windows).
// It doesn't seem to work with single quotes.

"run:all": "concurrently \"npm run devserver\" nodemon browsersync ios_webkit_debug_proxy ngrok-url"

При этом все 5 скриптов запускаются параллельно по одному терминалу. Потрясающие! Так что в этом пункте я редко использую gulp, поскольку существует так много сценариев cli для выполнения одних и тех же задач без кода.

Я предлагаю вам прочитать эти статьи, которые сравнивают их в глубине.

• Как использовать NPM в качестве инструмента сборки
• Почему мы должны прекратить использовать Grunt & Gulp
• Почему я оставил Gulp and Grunt для сценариев NPM

Я использовал оба варианта в разных проектах.

Вот один шаблонный , что я поставил вместе , используя gulpс webpack- https://github.com/iroy2000/react-reflux-boilerplate-with-webpack .

У меня есть другой проект, используемый только webpackс npm tasks.

И они оба работают совершенно нормально. И я думаю, что это сводится к тому, насколько сложна ваша задача, и какой контроль вы хотите иметь в своей конфигурации.

Например, если вы просто задачи, скажем dev, build, test... и т.д. (что очень стандарт), вы совершенно нормально только с простым webpackс npm tasks.

Но если у вас очень сложный рабочий процесс и вы хотите лучше контролировать свою конфигурацию (потому что это кодирование), вы можете пойти по пути gulp.

Но из моего опыта, экосистема веб-пакетов предоставляет более чем достаточно плагинов и загрузчиков, которые мне понадобятся, и поэтому я люблю использовать минимальный подход, если только вы не можете сделать что-то только в gulp. А также, это облегчит вашу настройку, если в вашей системе будет на одну вещь меньше.

И много раз, в настоящее время, я вижу, что люди фактически заменяют gulp and browsifyвсе вместе webpackодним.

Концепции Gulp и Webpack совершенно разные. Вы говорите Gulp, как пошагово собирать интерфейсный код, но вы говорите Webpack, что вы хотите через файл конфигурации.

Вот небольшая статья (прочитано 5 минут), которую я написал, объясняя мое понимание различий: https://medium.com/@Maokai/compile-the-front-end-from-gulp-to-webpack-c45671ad87fe

Наша компания перешла из Gulp в Webpack в прошлом году. Хотя это заняло некоторое время, мы выяснили, как перенести все, что мы делали в Gulp, на Webpack. Поэтому для нас все, что мы делали в Gulp, мы также можем делать через Webpack, но не наоборот.

На сегодняшний день я бы рекомендовал просто использовать Webpack и избегать сочетания Gulp и Webpack, чтобы вам и вашей команде не нужно было изучать и поддерживать оба, особенно потому, что они требуют очень разных подходов.

Честно говоря, я думаю, что лучше всего использовать оба.

• Веб-пакет для всех связанных с JavaScript .
• Глоток для всех связанных css .

Мне все еще нужно найти достойное решение для упаковки CSS с веб-пакетом, и до сих пор я счастлив использовать gulp для CSS и веб-пакет для javascript.

Я также использую npmсценарии как @Tetradev, как описано. Тем более что я пользуюсь Visual Studio, и хотя NPM Task runnerдовольно надежен Webpack Task Runner , довольно глючит .