Вопрос: NPM против Bower против Browserify против Gulp против Grunt против Webpack


Я пытаюсь обобщить свои знания о самых популярных менеджерах пакетов пакетов, поставщиках пакетов и задачах. Пожалуйста, поправьте меня, если я ошибаюсь:

  • npm& bowerявляются менеджерами пакетов. Они просто загружают зависимости и не знают, как создавать проекты самостоятельно. То, что они знают, - это позвонить webpack/ gulp/ gruntпосле получения всех зависимостей.
  • bowerкак npm, но строит сплющенные деревья зависимостей (в отличие от npmкоторые делают это рекурсивно). Имея в виду npmвыбирает зависимости для каждой зависимости (может получать одно и то же несколько раз), тогда как bowerожидает, что вы вручную включите субзависимости. Иногда bowerа также npmиспользуются вместе для интерфейсных и back-end соответственно (поскольку каждый мегабайт может иметь значение на интерфейсе).
  • gruntа также gulpявляются задачами для автоматизации всего, что может быть автоматизировано (т. е. скомпилировать CSS / Sass, оптимизировать изображения, сделать связку и минимизировать / перетащить ее).
  • gruntпротив gulp(как mavenпротив gradleили код конфигурации). Grunt основан на настройке отдельных независимых задач, каждая задача открывает / обрабатывает / закрывает файл. Gulp требует меньше кода и основан на потоках узлов, что позволяет ему строить цепочки труб (без повторного открытия одного и того же файла) и делает это быстрее.
  • webpack( webpack-dev-server) - для меня это бегун с горячей перезагрузкой изменений, который позволяет забыть обо всех наблюдателях JS / CSS.
  • npm/ bower+ плагины могут заменить задачи. Их способности часто пересекаются, поэтому есть разные последствия, если вам нужно использовать gulp/ gruntнад npm+ плагины. Но бегуны задач, безусловно, лучше подходят для сложных задач (например, «на каждой сборке создают пакет, переходят с ES6 на ES5, запускают его во всех эмуляторах браузеров, делают скриншоты и развертывают в Dropbox через ftp»).
  • browserifyпозволяет упаковывать узловые модули для браузеров. browserifyпротив node«s requireна самом деле AMD против CommonJS ,

Вопросов:

  1. Что webpack& webpack-dev-server? Официальная документация говорит, что это модуль-модуль, но для меня это просто задача. Какая разница?
  2. Где бы вы использовали browserify? Разве мы не можем сделать то же самое с импортом узлов / ES6?
  3. Когда вы будете использовать gulp/ gruntнад npm+ плагины?
  4. Приведите примеры, когда вам нужно использовать комбинацию

1473


источник


Ответы:


Webpack и Browserify

Webpack и Browserify выполняют практически ту же работу, что и обработка вашего кода, который будет использоваться в целевой среде (в основном браузер, хотя вы можете настроить таргетинг на другие среды, такие как Node). Результатом такой обработки является один или несколько пучки - собранные скрипты, подходящие для целевой среды.

Например, допустим, вы написали код ES6, разделенный на модули, и хотите иметь возможность запускать его в браузере. Если эти модули являются модулями Node, браузер не будет их понимать, поскольку они существуют только в среде Node. Модули ES6 также не будут работать в старых браузерах, таких как IE11. Кроме того, возможно, вы использовали экспериментальные языковые функции (ES следующие предложения), которые браузеры еще не реализуют, поэтому запуск такого скрипта просто приведет к ошибкам. Эти инструменты, такие как Webpack и Browserify, решают эти проблемы перевод такого кода в браузер формы может выполняться , Кроме того, они позволяют применять огромное разнообразие оптимизаций для этих пакетов.

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


Webpack Dev Server

Webpack Dev Server предоставляет аналогичное решение для Browsersync - сервера разработки, на котором вы можете быстро развертывать свое приложение, когда работаете над ним, и сразу же проверяйте прогресс разработки, когда сервер-разработчик автоматически обновляет браузер при изменении кода или даже распространяет измененный код на браузер без перезагрузки с так называемой горячей заменой модуля.


Бегущие задачи против NPM-скриптов

Я использовал Gulp для его краткости и легкого написания задачи, но позже выяснил, что мне не нужны ни Gulp, ни Grunt. Все, что мне когда-либо понадобилось, могло быть сделано с использованием сценариев NPM для запуска сторонних инструментов через их API. Выбор между сценариями Gulp, Grunt или NPM зависит от вкуса и опыта вашей команды.

Хотя задачи в Gulp или Grunt легко читаются даже для людей, не знакомых с JS, это еще один инструмент, который требует и учится, и я лично предпочитаю сузить свои зависимости и делать все просто. С другой стороны, заменяя эти задачи комбинацией сценариев NPM и (возможно, JS) скриптов, которые запускают сторонние инструменты (например, настройка и запуск сценария Node rimraf для очистки) может быть более сложной задачей. Но в большинстве случаев, эти три равны с точки зрения результатов.


Примеры

Что касается примеров, я предлагаю вам взглянуть на это Проект реактивного стартера , который показывает вам хорошую комбинацию NPM и JS-скриптов, охватывающих весь процесс сборки и развертывания. Вы можете найти эти NPM-скрипты в package.json в корневой папке в свойстве с именем scripts, Там вы будете чаще встречаться с командами вроде babel-node tools/run start, Babel-node - это инструмент CLI (не предназначен для использования в производстве), который сначала компилирует файл ES6 tools/run(файл run.js, расположенный в инструменты ) - в основном утилита для бегунов. Этот бегун принимает функцию в качестве аргумента и выполняет ее, что в этом случае start- другая утилита (start.js), ответственная за связывание исходных файлов (как с клиентом, так и с сервером) и запуск сервера приложений и разработки (dev-сервер будет, вероятно, Webpack Dev Server или Browsersync).

Говоря более точно, start.js создает как клиентские, так и серверные пакеты, запускает экспресс-сервер и после успешного запуска в браузере-синхронизации, который на момент написания выглядел так (см. реагировать стартовый проект для самого нового кода).

const bs = Browsersync.create();  
bs.init({
      ...(DEBUG ? {} : { notify: false, ui: false }),

      proxy: {
        target: host,
        middleware: [wpMiddleware, ...hotMiddlewares],
      },

      // no need to watch '*.js' here, webpack will take care of it for us,
      // including full page reloads if HMR won't work
      files: ['build/content/**/*.*'],
}, resolve)

Важная часть proxy.target, где они устанавливают адрес сервера, который они хотят прокси, который может быть HTTP: // локальный: 3000 , а Browsersync запускает сервер, прослушивающий HTTP: // локальный: 3001 , где сгенерированные активы обслуживаются с автоматическим обнаружением изменений и заменой горячего модуля. Как вы можете видеть, существует еще одно свойство конфигурации filesс отдельными файлами или шаблонами. Браузер-синхронизация часов для изменений и перезагрузки браузера, если они встречаются, но, как говорится в комментарии, Webpack заботится о том, чтобы просматривать js-источники самостоятельно с помощью HMR, поэтому они там сотрудничают.

Теперь у меня нет эквивалентного примера такой конфигурации Grunt или Gulp, но с Gulp (и несколько аналогично с Grunt) вы должны писать отдельные задачи в gulpfile.js, например

gulp.task('bundle', function() {
  // bundling source files with some gulp plugins like gulp-webpack maybe
});

gulp.task('start', function() {
  // starting server and stuff
});

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


781



Обновление июня 2018 года

Изучение современного JavaScript жестко, если вы не были там с самого начала. Если вы новый посетитель, не забудьте проверить этот отличный письменный, чтобы получить лучший обзор.

https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70

Обновление июля 2017 года

Недавно я нашел действительно полное руководство от команды Grab о том, как подойти к разработке интерфейса в 2017 году. Вы можете проверить это, как показано ниже.

https://github.com/grab/front-end-guide


Я также искал это довольно долгое время, так как там есть много инструментов, и каждый из них приносит нам пользу в другом аспекте. Сообщество делится на такие инструменты, как Browserify, Webpack, jspm, Grunt and Gulp, Вы также можете услышать о Yeoman or Slush, Это не проблема, это просто путано для всех, кто пытается понять четкий путь вперед.

Во всяком случае, я хотел бы что-то внести.

1. Менеджер пакетов

Менеджеры пакетов упрощают установку и обновление зависимостей проекта, которые являются библиотеками, такими как: jQuery, Bootstrap, и т. д. - все, что используется на вашем сайте и не написано вами.

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

  • NPMозначает: Node JS package managerпоможет вам управлять всеми библиотеками, на которые опирается ваше программное обеспечение. Вы бы определили ваши потребности в файле с именем package.jsonи запустить npm installв командной строке ... затем BANG, ваши пакеты загружаются и готовы к использованию. Может использоваться как для front-end and back-endбиблиотеки.

  • Bower: для управления интерфейсом переднего плана концепция аналогична концепции NPM. Все ваши библиотеки хранятся в файле с именем bower.jsonа затем запустить bower installв командной строке.

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

Цитата из В чем разница между Bower и npm?

NPM

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

осенять

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

Есть некоторые обновления на npm 3 Duplication and Deduplication,   пожалуйста, откройте документ для более подробной информации.

  • Yarn: Новый менеджер пакетов для JavaScript опубликованный от Facebookнедавно с некоторыми преимуществами по сравнению с NPM, И с пряжей вы все еще можете использовать оба NPMа также Bowerреестра для извлечения пакета. Если вы установили пакет раньше, yarnсоздает кешированную копию, которая облегчает offline package installs,

  • jspm: это менеджер пакетов для SystemJSуниверсальный загрузчик модулей, построенный на основе динамического ES6загрузчик модулей. Это не совсем новый менеджер пакетов с собственным набором правил, скорее он работает поверх существующих источников пакетов. Из коробки он работает с GitHubа также npm, Поскольку большинство Bowerоснованные на GitHub, мы можем установить эти пакеты, используя jspmтакже. В нем есть реестр, в котором перечислены большинство распространенных интерфейсных пакетов для упрощения установки.

Смотрите разницу между Bowerа также jspm: Менеджер пакетов: Bower vs jspm


2. Загрузочный модуль / комплектация

Большинство проектов любого масштаба будут разделять их код между несколькими файлами. Вы можете просто включить каждый файл в отдельную <script>тег, однако, <script>устанавливает новое http-соединение, а для небольших файлов - цель модульности - время установления соединения может занять значительно больше времени, чем передача данных. Пока скрипты загружаются, контент не может быть изменен на странице.

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

Например

<head>
    <title>Wagon</title>
    <script src=“build/wagon-bundle.js”></script>
</head>
  • Однако производительность достигается за счет гибкости. Если ваши модули имеют взаимозависимость, это отсутствие гибкости может быть showstopper.

Например

<head>
    <title>Skateboard</title>
    <script src=“connectors/axle.js”></script>
    <script src=“frames/board.js”></script>
    <!-- skateboard-wheel and ball-bearing both depend on abstract-rolling-thing -->
    <script src=“rolling-things/abstract-rolling-thing.js”></script>
    <script src=“rolling-things/wheels/skateboard-wheel.js”></script>
    <!-- but if skateboard-wheel also depends on ball-bearing -->
    <!-- then having this script tag here could cause a problem -->
    <script src=“rolling-things/ball-bearing.js”></script>
    <!-- connect wheels to axle and axle to frame -->
    <script src=“vehicles/skateboard/our-sk8bd-init.js”></script>
</head>

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

Затем мы услышали о RequireJS, Browserify, Webpackа также SystemJS

  • RequireJS: это JavaScriptзагрузку файлов и модулей. Он оптимизирован для использования в браузере, но его можно использовать в других средах JavaScript, например Node,

Например: myModule.js

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

В main.js, мы можем импортировать myModule.jsкак зависимость и использовать ее.

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

И затем в нашем HTML, мы можем ссылаться на RequireJS,

<script src=“app/require.js” data-main=“main.js” ></script>

Узнайте больше о CommonJSа также AMDчтобы легко понять. Связь между CommonJS, AMD и RequireJS?

  • Browserify: предусмотреть возможность использования CommonJSотформатированных модулей в браузере. Вследствие этого, Browserifyне столько загрузчик модулей, сколько модуль-модуль: Browserifyявляется полностью инструментом построения времени, создавая пакет кода, который затем может быть загружен на стороне клиента.

Начните с сборки, на которой установлен узел и npm, и получите пакет:

npm install -g –save-dev browserify

Напишите свои модули в CommonJSформат

//entry-point.js
var foo = require('../foo.js');
console.log(foo(4));

И когда вы счастливы, выполните команду для объединения:

browserify entry-point.js -o bundle-name.js

Browserify рекурсивно находит все зависимости точки входа и собирает их в один файл:

<script src=”bundle-name.js”></script>
  • Webpack: Он объединяет все ваши статические активы, в том числе JavaScript, изображения, CSS и многое другое, в один файл. Он также позволяет обрабатывать файлы с помощью различных типов загрузчиков. Вы можете написать свой JavaScriptс CommonJSили AMDсинтаксис модулей. Он атакует проблему сборки в принципиально более интегрированной и упрямой манере. В Browserifyты используешь Gulp/Gruntи длинный список преобразований и плагинов, чтобы выполнить работу. Webpackпредлагает достаточно мощности из коробки, что вам обычно не нужно Gruntили Gulpвообще.

Основное использование не просто. Установите Webpack как Browserify:

npm install -g –save-dev webpack

И передайте команде точку входа и выходной файл:

webpack ./entry-point.js bundle-name.js
  • SystemJS: является загрузчиком модуля, который может импортировать модули во время выполнения в любом из популярных форматов используется сегодня ( CommonJS, UMD, AMD, ES6). Он построен поверх ES6модульный загрузчик polyfill и достаточно умен, чтобы определить используемый формат и соответствующим образом обрабатывать его. SystemJSможет также преобразовать код ES6 (с Babelили Traceur) или на других языках, таких как TypeScriptа также CoffeeScriptиспользуя плагины.

Хотите знать, что такое node moduleи почему он плохо адаптирован к браузеру.

Более полезная статья:


Зачем jspmа также SystemJS?

Одна из основных целей ES6модульность - сделать его действительно простым   для установки и использования любой библиотеки Javascript из любого места на   Интернет ( Github, npm, и т.д.). Требуются только две вещи:

  • Одна команда для установки библиотеки
  • Одна строка кода для импорта библиотеки и использования ее

Таким образом, с jspm, ты можешь это сделать.

  1. Установите библиотеку с помощью команды: jspm install jquery
  2. Импортируйте библиотеку с одной строкой кода, без необходимости внешней ссылки внутри HTML-файла.

display.js

var $ = require('jquery'); 

$('body').append("I've imported jQuery!");
  1. Затем вы настраиваете эти вещи в пределах System.config({ ... })до   импортируя ваш модуль. Обычно при запуске jspm init, будет файл   названный config.jsдля этой цели.

  2. Чтобы эти сценарии выполнялись, нам нужно загрузить system.jsа также config.jsна странице HTML. После этого мы будем загружать display.jsиспользование файла    SystemJSзагрузчик модулей.

index.html

<script src="jspm_packages/system.js"></script>
<script src="config.js"></script>
<script>
  System.import("scripts/display.js");
</script>

Отмечено: вы также можете использовать npmс Webpackкак угловой 2. поскольку jspmбыла разработана для интеграции с SystemJSи он работает поверх существующих npmисточник, поэтому ваш ответ зависит от вас.


3. Запуск задания

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

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

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

grunt.initConfig({
  clean: {
    src: ['build/app.js', 'build/vendor.js']
  },

  copy: {
    files: [{
      src: 'build/app.js',
      dest: 'build/dist/app.js'
    }]
  }

  concat: {
    'build/app.js': ['build/vendors.js', 'build/app.js']
  }

  // ... other task configurations ...

});

grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);
  • Gulp: Автоматизация как раз Gruntно вместо конфигураций вы можете написать JavaScriptс потоками, как это приложение-узел. Предпочитаю в эти дни.

Это Gulpобразец декларации задачи.

//import the necessary gulp plugins
var gulp = require('gulp');
var sass = require('gulp-sass');
var minifyCss = require('gulp-minify-css');
var rename = require('gulp-rename');

//declare the task
gulp.task('sass', function(done) {
  gulp.src('./scss/ionic.app.scss')
    .pipe(sass())
    .pipe(gulp.dest('./www/css/'))
    .pipe(minifyCss({
      keepSpecialComments: 0
    }))
    .pipe(rename({ extname: '.min.css' }))
    .pipe(gulp.dest('./www/css/'))
    .on('end', done);
});

Узнать больше: https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri


4. Лесные инструменты

  • Slush and Yeoman: Вы можете создавать с ними стартовые проекты. Например, вы планируете создавать прототип с помощью HTML и SCSS, а затем вручную создавать некоторые папки, такие как scss, css, img, fonts. Вы можете просто установить yeomanи запустить простой скрипт. Тогда все здесь для вас.

Найди больше Вот ,

npm install -g yo
npm install --global generator-h5bp
yo h5bp

Узнать больше: https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express


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


537



Вы можете найти техническое сравнение npmcompare

Сравнение браузеров против хрюка против gulp vs. webpack

Как вы можете видеть, webpack очень ухожен с новой версией, выходящей каждые 4 дня в среднем. Но у Gulp, похоже, есть самое большое сообщество из всех (с более чем 20K звездами в Github) Грунт кажется немного пренебрегаемым (по сравнению с другими)

Поэтому, если нужно выбрать один над другим, я бы пошел с Gulp


44



в порядке, все они имеют некоторое сходство, они делают то же самое для вас разными и похожими способами, я делю их в 3 основных группы как показано ниже:


1) Модульные модули

webpack и браузеризировать как популярные, работать как бегуны задач, но с большей гибкостью, а также объединить все вместе как ваш параметр, так что вы можете указать на результат как bundle.js, например, в одном файле, включая CSS и Javascript, для более подробную информацию о каждом из них см. ниже:

WebPack

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

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

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

Больше Вот

browserify

Browserify - это инструмент разработки, который позволяет нам писать node.js-style   модули, которые компилируются для использования в браузере. Подобно узлу, мы пишем   наши модули в отдельных файлах, экспорт внешних методов и   с использованием переменных module.exports и экспорта. Мы можем даже   требуют использования других модулей с использованием функции require, и если мы опустим   относительный путь, который он разрешит модулю в node_modules   каталог.

Больше Вот


2) Бегуны задач

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

глоток

gulp.js - это инструментарий JavaScript с открытым исходным кодом от Fractal Innovations   и сообщество с открытым исходным кодом в GitHub, используемое как потоковая сборка   системы в интерфейсе веб-разработки. Это задача, построенная на   Node.js и диспетчер пакетов узлов (npm), используемый для автоматизации   трудоемкие и повторяющиеся задачи, связанные с веб-разработкой, такими как   минимизация, конкатенация, сбой кэша, модульное тестирование, листинг,   оптимизация и т. д. gulp использует подход с кодовой конфигурацией для   определить свои задачи и полагаться на свои малые однонаправленные плагины на   вынести их. экосистема gulp имеет 1000+ таких плагинов, доступных   выбирать из.

Больше Вот

хрюкать

Grunt - это бегун для задач JavaScript, инструмент, используемый для автоматического   выполнять часто используемые задачи, такие как минимизация, компиляция, единица   тестирование, листинг и т. д. Он использует интерфейс командной строки для запуска пользовательских   задачи, определенные в файле (известный как файл Grunt). Grunt был создан   Бен Альман и написан в Node.js. Он распространяется через npm.   В настоящее время доступно более пяти тысяч плагинов в   Грунт экосистемы.

Больше Вот


3) Менеджеры пакетов

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

НПМ

npm - это менеджер пакетов для языка программирования JavaScript. Это   это менеджер пакетов по умолчанию для среды выполнения JavaScript   Node.js. Он состоит из клиента командной строки, также называемого npm, и   онлайн-базу данных общих пакетов, называемую реестром npm.   доступ к реестру осуществляется через клиента, а доступные пакеты могут быть   просматривается и просматривается через сайт npm.

Больше Вот

осенять

Bower может управлять компонентами, которые содержат HTML, CSS, JavaScript, шрифты   или даже файлы изображений. Bower не объединяет и не кодирует код или не делает   ничего другого - он просто устанавливает правильные версии пакетов   вам нужны и их зависимости.   Чтобы начать работу, Bower работает, выбирая и устанавливая пакеты из   во всем, заботясь о охоте, поиске, загрузке и сохранении   вещи, которые вы ищете. Bower отслеживает эти пакеты в   файл манифеста, bower.json.

Больше Вот

и самый последний менеджер пакетов, который не следует упускать, он молод и быстр в реальной рабочей среде, сравнивая с npm, который я использовал раньше, для переустановки модулей он дважды проверяет папку node_modules, чтобы проверить наличие модуля, также кажется, что установка модулей занимает меньше времени:

пряжа

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

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

Код передается через нечто, называемое пакетом (иногда называемым   как модуль). Пакет содержит весь общий код.   как файл package.json, который описывает пакет.

Больше Вот



41



A small note about npm: npm3 tries install dependencies in a flat way

https://docs.npmjs.com/how-npm-works/npm3#npm-v3-dependency-resolution


40



What is webpack & webpack-dev-server? Official documentation says it's a module bundler but for me it's just a task runner. What's the difference?

webpack-dev-server is a live reloading web server that Webpack developers use to get immediate feedback what they do. It should only be used during development.

This project is heavily inspired by the nof5 unit test tool.

Webpack as the name implies will create a SINGLE package for the web. The package will be minimized, and combined into a single file (we still live in HTTP 1.1 age). Webpack does the magic of combining the resources (JavaScript, CSS, images) and injecting them like this: <script src="assets/bundle.js"></script>.

It can also be called module bundler because it must understand module dependencies, and how to grab the dependencies and to bundle them together.

Where would you use browserify? Can't we do the same with node/ES6 imports?

You could use Browserify on the exact same tasks where you would use Webpack. – Webpack is more compact, though.

Note that the ES6 module loader features in Webpack2 are using System.import, which not a single browser supports natively.

When would you use gulp/grunt over npm + plugins?

You can forget Gulp, Grunt, Brokoli, Brunch and Bower. Directly use npm command line scripts instead and you can eliminate extra packages like these here for Gulp:

var gulp        = require('gulp'),
  minifyCSS     = require('gulp-minify-css'),
  sass          = require('gulp-sass'),
  browserify    = require('gulp-browserify'),
  uglify        = require('gulp-uglify'),
  rename        = require('gulp-rename'),
  jshint        = require('gulp-jshint'),
  jshintStyle   = require('jshint-stylish'),
  replace       = require('gulp-replace'),
  notify        = require('gulp-notify'),

You can probably use Gulp and Grunt config file generators when creating config files for your project. This way you don't need to install Yeoman or similar tools.


10



Yarn is a recent package manager that probably deserves to be mentioned. So, there : https://yarnpkg.com/

Afaik, it can fetch both npm and bower dependencies and has other appreciated features.


9



StackShare provides a side-by-side (or stack up) of three tools at one time.

Here it is for npm vs. Bower vs. Browserify and for gulp vs. Webpack vs. Grunt

On these comparison pages you can find the following:

  • number of votes each has received from the StackShare community
  • which companies use them in their tech stack
  • interest level for each over time
  • pros for each tool

4



Webpack is a bundler. Like Browserfy it looks in the codebase for module requests (require or import) and resolves them recursively. What is more, you can configure Webpack to resolve not just JavaScript-like modules, but CSS, images, HTML, literally everything. What especially makes me excited about Webpack, you can combine both compiled and dynamically loaded modules in the same app. Thus one get a real performance boost, especially over HTTP/1.x. How exactly you you do it I described with examples here http://dsheiko.com/weblog/state-of-javascript-modules-2017/ As an alternative for bundler one can think of Rollup.js (https://rollupjs.org/), which optimizes the code during compilation, but stripping all the found unused chunks.

For AMD, instead of RequireJS one can go with native ES2016 module system, but loaded with System.js (https://github.com/systemjs/systemjs)

Besides, I would point that npm is often used as an automating tool like grunt or gulp. Check out https://docs.npmjs.com/misc/scripts. I personally go now with npm scripts only avoiding other automation tools, though in past I was very much into grunt. With other tools you have to rely on countless plugins for packages, that often are not good written and not being actively maintained. npm knows its packages, so you call to any of locally installed packages by name like:

{
  "scripts": {
    "start": "npm http-server"
  },
  "devDependencies": {
    "http-server": "^0.10.0"
  }
}

Actually you as a rule do not need any plugin if the package supports CLI.


4