Через Gulp + Webpack или просто Webpack?

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

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

С Webpack + npm скрипты, это так просто:

"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, один для режима разработки,webpack.development.js, и один для режим производства webpack.production.js. Я также использую webpack.common.js который содержит конфигурацию webpack, общую для всех сред, и использует webpackMerge для их слияния.

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

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

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

The pre и post префиксы сообщают NPM, в каком порядке выполнять.

если вы заметили, с webpack + npm скрипты, вы можете запустить собственные программы, такие как rimraf, вместо gulp-обертки для родной программы, такой как gulp-rimraf. Вы также можете запускать собственные окна .EXE файлы, как я сделал здесь с elevate.exe или родной * nix файлы на Linux или Mac.

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

Gulp Development code

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 Production code

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));
};

фактический код gulp намного сложнее, чем это, так как это только 2 из нескольких десятков файлов gulp в РЕПО.

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

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

обновление

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

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

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

поэтому я создал очень простую задачу gulp, которая просто запускает мои сценарии NPM или команды напрямую, поэтому все выходные данные отображаются в одном окне, и я могу легко закончить все 5 серверов сразу, закрыв окно задачи 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, чтобы помочь. Выбрать правильный инструмент для правильной работы.

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

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

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

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

у меня есть какой-то другой проект использовал только webpack С npm tasks.

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

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

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

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

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

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

• Webpack для всех javascript связанные.
• залпом для всех css связанные.

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

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

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

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

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

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