Фронтенд-инжиниринг — выбор инструментов сборки: grunt, gulp, webpack

Webpack внешний фреймворк
Фронтенд-инжиниринг — выбор инструментов сборки: grunt, gulp, webpack

Примечание. Статья создана в результате внутреннего обмена в августе 2017 года, и некоторые данные могут быть устаревшими.

1. Что такое фронтенд-инжиниринг

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

2. Почему фронтенд-инжиниринг

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

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

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

3. Инструменты для сборки

Основная функция инструментов построения — автоматизация обработки, такой как проверка, предварительная компиляция, слияние и сжатие кода, создание карт Sprite, исходных карт, управление версиями, выполнение модульных тестов, мониторинг и т. д. Конечно, некоторые инструменты также обеспечивают модульность и компонентизацию. функция процесса разработки.

В Интернете есть множество инструментов для конструирования, в том числе известные Grunt, Gulp, Webpack и инструменты для конструирования с открытым исходным кодом от крупных команд компаний.Вот простое сравнение популярности каждого инструмента на основе количества звезд. на Гитхабе:

stars.png

Если инструменты разделить по типу, то их можно разделить на три категории:

  1. Инструменты запускаются на основе задач:
    хрюканье, глоток
    Они будут автоматически выполнять заданные задачи, такие как конвейеры, размещать на них ресурсы, а затем обрабатывать их с помощью различных плагинов.Они включают в себя активные сообщества, богатые плагины и могут легко создавать различные рабочие процессы.

  2. Инструменты на основе модульной упаковки:
    Browserify, Webpack, rollup.js
    Те, у кого есть опыт разработки Node.js, должны быть знакомы с модулями и должны напрямую ссылаться на компонент.requireПросто хорошо, этот тип инструмента - это этот режим, и он также может загружать модули по запросу и асинхронно.

  3. Интегрированные инструменты:
    Йомен, FIS, jdf, Афина, кулинария, weflow
    Преимущество инструментов формирования шаблонов, реализованных с использованием нескольких технологических стеков, состоит в том, что они нестандартны, но недостатком является то, что они ограничивают выбор технологий, а стоимость обучения относительно высока.

В-четвертых, выбор строительных инструментов

При выборе мы часто учитываем следующие факторы:

  1. Соответствует ли он технологическому стеку команды?
  2. Отвечает ли он требованиям проекта
  3. Завершена ли экосистема и активно ли сообщество?

Или, чтобы исключить субъективные факторы 1 и 2, мы выбираем несколько популярных (удовлетворяющий фактор 3) среди разных типов инструментов, а именно: Grunt, Gulp, Webpack, Yeoman, чтобы увидеть их рабочий процесс, преимущества и недостатки, а также применимые сценарии.

1. Ворчание и глоток

Рабочий процесс:
Оба инструмента основаны на типах задач, поэтому их рабочий процесс согласован:

gulp_workflow.png

Видно, что их стратегия упаковки обычно «Все в одном», а конечная страница по-прежнему ссылается на css, img, js, а процесс разработки ничем не отличается от разработки от руки.

Особенности и недостатки
Grunt
Grunt — это старомодный инструмент сборки, который характеризуется конфигурацией.Все, что вам нужно сделать, это понять функции различных плагинов, а затем интегрировать конфигурацию в Gruntfile.js.Вы можете увидеть следующий пример конфигурации, который просто и понятно:

module.exports = function(grunt) {
  grunt.initConfig({
    jshint: {
      files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'],
      options: {
        globals: {
          jQuery: true
        }
      }
    },
    watch: {
      files: ['<%= jshint.files %>'],
      tasks: ['jshint']
    }
  });

  grunt.loadNpmTasks('grunt-contrib-jshint');
  grunt.loadNpmTasks('grunt-contrib-watch');

  grunt.registerTask('default', ['jshint']);
};

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

Читать меньше файла -> скомпилировать в css -> сохранить на диск -> прочитать css -> сжать -> сохранить на диск

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

Gulp
Gulp управляется кодом, и написание задач такое же, как написание обычного кода Node.js:

var gulp = require('gulp');
var pug = require('gulp-pug');
var less = require('gulp-less');
var minifyCSS = require('gulp-csso');

gulp.task('html', function(){
  return gulp.src('client/templates/*.pug')
    .pipe(pug())
    .pipe(gulp.dest('build/html'))
});

gulp.task('css', function(){
  return gulp.src('client/templates/*.less')
    .pipe(less())
    .pipe(minifyCSS())
    .pipe(gulp.dest('build/css'))
});

gulp.task('default', [ 'html', 'css' ]);

Другим примером чтения файла является потоковая операция (Stream), что означает, что один ввод-вывод может обрабатывать несколько задач, или пример меньшего количества.Процесс Gulp:

Читать меньше файла -> скомпилировать в css -> сжать -> сохранить на диск

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

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

2. Веб-пакет
Webpack в настоящее время является самым популярным интерфейсным инструментом модульного управления и упаковки ресурсов.Давайте сначала разберемся, как он работает с изображением:

Рабочий процесс

webpack_workflow.png

Особенности и недостатки
Особенности веб-пакета:

  1. Относитесь ко всему как к модулю: CSS, JS, Image или HTML могут ссылаться друг на друга, определяя entry.js, отслеживать все зависимые файлы, обрабатывать каждый модуль с помощью загрузчиков и плагинов, а затем упаковывать их вместе.
  2. Загрузка по запросу: в процессе упаковки Webpack делит файл на несколько фрагментов с помощью функции разделения кода, а также может извлекать повторяющиеся части отдельно как общий фрагмент, чтобы реализовать загрузку по требованию.

Webpack также управляется через конфигурацию.В отличие от Grunt, он содержит много автоматизированных операций черного ящика, поэтому его намного проще настроить (но очень проблематично отлаживать при возникновении проблем).Типичная конфигурация выглядит следующим образом:

module.exports = {
    //插件项
    plugins: [commonsPlugin],
    //页面入口文件配置
    entry: {
        index : './src/js/page/index.js'
    },
    //入口文件输出配置
    output: {
        path: 'dist/js/page',
        filename: '[name].js'
    },
    module: {
        //加载器配置
        loaders: [
            { test: /\.css$/, loader: 'style-loader!css-loader' },
            { test: /\.js$/, loader: 'jsx-loader?harmony' },
            { test: /\.scss$/, loader: 'style!css!sass?sourceMap'},
            { test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'}
        ]
    },
    //其它解决方案配置
    resolve: {
        root: '/Users/Bell/github/flux-example/src', //绝对路径
        extensions: ['', '.js', '.json', '.scss'],
        alias: {
            AppStore : 'js/stores/AppStores.js',
            ActionType : 'js/actions/ActionType.js',
            AppAction : 'js/actions/AppAction.js'
        }
    }
};

Недостатки веб-пакета:

  1. Начать сложно: официальная документация запутана, конфигурация сложная, отлаживать сложно (намного лучше Webpack2), для новичков необходимо пройти процесс наступания на яму;
  2. Немного бессилен для многостраничных приложений, отображаемых на стороне сервера: Webpack изначально был разработан для SPA, поэтому при работе с многостраничными приложениями, отображаемыми на стороне сервера, независимо от того, как вы разбиваете их на фрагменты, вы не можете достичь точки включения. требуют загрузки, и вам часто приходится думать, как извлечь общедоступные файлы для достижения оптимального состояния.

Модульность и компонентизация
Когда дело доходит до Webpack, мы должны поговорить о его модульном методе загрузки.Давайте сначала рассмотрим традиционный модульный метод:

├── scripts/
│    ├── dropdown.js
│    ├── lazyload.js
│    ├── modal.js
│    └── slider.js
├── styles/
│    ├── button.less
│    ├── list.less
│    ├── modal.less
│    └── slider.less

Традиционная модульность основана на едином языке программирования для разделения и повторного использования.Однако из-за особенностей самого интерфейса (требуется взаимодействие трех языков программирования) и ограничений возможностей сложно добиться компонентизации при перекрестном использовании. - загрузка ресурсов не может быть достигнута.

Ограничение мышления, которое ломает Webpack, его концепция «требовать чего-либо» может одновременно реализовать модульность и компонентизацию.С помощью Webpack можно легко реализовать эту структуру организации кода:

├──components/
│    ├── button/
│    │    ├── button.js
│    │    ├── button.less
│    │    ├── dropdwon.js
│    │    └── icon.png
│    ├── modal/
│    ├── slider/

Как только компонентизация реализована, наш метод разработки проекта и метод разделения труда и сотрудничества могут быть обновлены, что может реализовать параллельную разработку подкомпонентов, а также может легко ссылаться на компоненты, используемые другими проектами:

Проект А

компоненты Разработчик
Вкладка Сяо Мин
Информационный список Ватсон
вращающийся фонарь Чжугэ
модальное окно мультиплекс

Проект Б

компоненты Разработчик
Вкладка мультиплекс
кнопка Сяо Ди
модальное окно Лонг Чен
загрузить старая лошадь

Таким образом, можно сказать, что компонентизация — лучшее решение для повышения эффективности совместной работы нескольких человек в крупномасштабных проектах!

Применимая сцена:
Таким образом, Webpack особенно подходит для создания одностраничных приложений с React.js и Vue.js, а также для крупномасштабных проектов, требующих сотрудничества нескольких человек.Когда стандартный процесс согласован, он часто может значительно повысить эффективность разработки и разработки. опыт. .

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

использованная литература

Категории