Unterschied zwischen Grunt, NPM und Bower (package.json vs bower.json)

Question

Wenn ich ein Paket hinzufügen möchte (und die Abhängigkeit in git einchecken möchte), wo gehört es hin - in die package.json oder in die bower.json?

Wie ich verstehe,
das Ausführen von bower install wird das Paket abrufen und es in das /vendor-Verzeichnis legen,
das Ausführen von npm install wird es abrufen und es in das /node_modules-Verzeichnis legen.

Diese SO-Antwort besagt, dass Bower für Front-End und npm für Backend-Stuff ist.
Ember-app-kit scheint sich auf den ersten Blick an diese Unterscheidung zu halten... Aber die Anweisungen in der Gruntfile für das Aktivieren einiger Funktionen geben zwei explizite Befehle, also bin ich total verwirrt.

Intuitiv würde ich vermuten, dass

1. npm install --save-dev Paketname dem Hinzufügen des Paketnamens zu meiner package.json entspricht

2. bower install --save Paketname könnte dasselbe sein wie das Hinzufügen des Pakets zu meiner bower.json und das Ausführen von bower install?

Wenn das der Fall ist, wann sollte ich jemals Pakete explizit auf diese Weise installieren, ohne sie zu der Datei hinzuzufügen, die die Abhängigkeiten verwaltet (abgesehen von der Installation von Befehlszeilentools global)?

Answer 1

Npm und Bower sind beide Werkzeuge zur Abhängigkeitsverwaltung. Der Hauptunterschied zwischen beiden ist, dass npm zur Installation von Node.js-Modulen verwendet wird, während Bower zur Verwaltung von Front-End-Komponenten wie HTML, CSS, JS usw. verwendet wird.

Ein Fakt, der dies noch verwirrender macht, ist, dass npm auch einige Pakete bereitstellt, die auch für die Front-End-Entwicklung verwendet werden können, wie z.B. grunt und jshint.

Diese Zeilen fügen mehr Bedeutung hinzu

Bower kann im Gegensatz zu npm mehrere Dateien (z.B. .js, .css, .html, .png, .ttf) haben, die als Hauptdatei(en) betrachtet werden. Bower betrachtet semantisch diese Hauptdateien, wenn sie zusammen verpackt sind, als Komponente.

Bearbeiten: Grunt ist ziemlich anders als Npm und Bower. Grunt ist ein JavaScript-Task-Runner-Tool. Mit Grunt können Sie viele Dinge tun, die Sie sonst manuell erledigen müssten. Hier sind einige Verwendungszwecke von Grunt hervorgehoben:

1. Dateien zippen (z.B. mit dem zipup-Plugin)
2. Linting auf JS-Dateien (jshint)
3. Kompilieren von Less-Dateien (grunt-contrib-less)

Es gibt Grunt-Plugins für Sass-Kompilierung, Uglify Ihres JavaScripts, Kopieren von Dateien/Ordnern, Minifizierung von JavaScript usw.

Bitte beachten Sie, dass ein Grunt-Plugin auch ein npm-Paket ist.

Frage-1

Wenn ich ein Paket hinzufügen möchte (und die Abhängigkeit in git überprüfen), wo gehört es hin - in die package.json oder in die bower.json

Es hängt wirklich davon ab, wo dieses Paket hingehört. Wenn es sich um ein Node-Modul handelt (wie Grunt, Request), dann kommt es in die package.json, ansonsten in die bower.json.

Frage-2

Wann sollte ich jemals Pakete explizit installieren, ohne sie der Datei hinzuzufügen, die die Abhängigkeiten verwaltet

Es spielt keine Rolle, ob Sie Pakete explizit installieren oder die Abhängigkeit in der .json-Datei angeben. Angenommen, Sie arbeiten an einem Node-Projekt und benötigen ein weiteres Projekt, sagen wir request, dann haben Sie zwei Optionen:

• Bearbeiten Sie die package.json-Datei und fügen Sie eine Abhängigkeit zu 'request' hinzu
• npm install

ODER

• Verwenden Sie die Befehlszeile: npm install --save request

Die Option --save fügt die Abhängigkeit auch zur package.json-Datei hinzu. Wenn Sie die Option --save nicht angeben, wird das Paket nur heruntergeladen, aber die json-Datei bleibt unverändert.

Sie können dies auf beide Arten tun, es wird keinen wesentlichen Unterschied geben.

Answer 2

Aktualisierung für Mitte 2016:

Die Dinge ändern sich so schnell, dass diese Antwort bis Ende 2017 möglicherweise nicht mehr aktuell ist!

Anfänger können sich schnell in der Auswahl von Build-Tools und Workflows verlieren, aber das Neueste im Jahr 2016 ist es, überhaupt nicht Bower, Grunt oder Gulp zu verwenden! Mit Hilfe von Webpack können Sie alles direkt in NPM erledigen!

• Google "npm als Build-Tool" Ergebnis: https://medium.com/@dabit3/einführung-in-die-verwendung-von-npm-als-build-tool-b41076f488b0#.c33e74tsa

• Webpack: https://webpack.github.io/docs/installation.html

Verstehen Sie mich nicht falsch, es gibt andere Workflows und ich verwende immer noch GULP in meinem Legacy-Projekt (bewege mich aber langsam davon weg), aber so machen es die besten Unternehmen und Entwickler, die in diesem Workflow arbeiten, verdienen eine MENGE Geld!

Schauen Sie sich dieses Template an, es handelt sich um ein sehr aktuelles Setup, bestehend aus einer Mischung der besten und neuesten Technologien: https://github.com/coryhouse/react-slingshot

• Webpack
• NPM als Build-Tool (kein Gulp, Grunt oder Bower)
• React mit Redux
• ESLint
• die Liste ist lang. Gehen Sie und erkunden Sie!

Ihre Fragen:

Wenn ich ein Paket hinzufügen möchte (und die Abhängigkeit in Git überprüfen möchte), wo gehört es hin - in package.json oder in bower.json

• Alles gehört jetzt in die package.json

• Für den Build erforderliche Abhängigkeiten sind in "devDependencies" d.h. npm install require-dir --save-dev (--save-dev aktualisiert Ihre package.json, indem ein Eintrag zu devDependencies hinzugefügt wird)

• Für Ihre Anwendung zur Laufzeit erforderliche Abhängigkeiten sind in "dependencies" d.h. npm install lodash --save (--save aktualisiert Ihre package.json, indem ein Eintrag zu dependencies hinzugefügt wird)

Wenn das der Fall ist, wann sollte ich jemals Pakete explizit auf diese Weise installieren, ohne sie in die Datei zu übernehmen, die die Abhängigkeiten verwaltet (außer bei der Installation von Befehlszeilentools global)?

Immer. Nur aus Komfort. Wenn Sie eine Flagge hinzufügen (--save-dev oder --save), wird die Datei, die die Abhängigkeiten verwaltet (package.json), automatisch aktualisiert. Verschwenden Sie keine Zeit damit, Abhängigkeiten manuell darin zu bearbeiten. Die Abkürzung für npm install --save-dev package-name ist npm i -D package-name und die Abkürzung für npm install --save package-name ist npm i -S package-name