Wie zum Teufel installiert man ein bestehendes Npm-Projekt?

Wir haben an dieser Stelle einen guten Überblick darüber bekommen, wie Npm funktioniert und wie man es zur Installation von Paketen und Ausführung von Befehlen verwendet. Nun wollen wir etwas weiter gehen und sehen, wie es aussieht, ein *bestehendes* Npm-Projekt herunterzuladen und zu installieren, anstatt eines von Grund auf neu zu erstellen. Höchstwahrscheinlich werden Sie das die meiste Zeit tun. Es ist viel, viel einfacher, als alle einzelnen Teile einzeln zu installieren und zu konfigurieren.

Das behandeln wir im letzten Kapitel dieses Leitfadens zu Npm, und ich werde aus meiner persönlichen Erfahrung mit einem meiner realen Projekte schöpfen.

Kapitel des Leitfadens

1. Für wen ist diese Anleitung?
2. Was zum Teufel bedeutet „npm“?
3. Was zum Teufel ist die Befehlszeile?
4. Was zum Teufel ist Node?
5. Was zum Teufel ist ein Paketmanager?
6. Wie zum Teufel installiert man npm?
7. Wie zum Teufel installiert man npm-Pakete?
8. Was zum Teufel sind npm-Befehle?
9. Wie zum Teufel installiert man ein bestehendes Npm-Projekt? (Sie sind hier!)

Hier ist ein echtes Npm-Projekt

Das Projekt, das ich dafür ausgewählt habe, ist mein eigener SvelteKit Static Blog Starter. Ich denke, es ist ein schönes Beispiel, weil es viele vorinstallierte Pakete enthält, die sich gut für Demonstrationszwecke eignen.

Dies ist ein echtes Projekt von mir, das Ihnen – wie Sie es sich vielleicht schon anhand des Namens gedacht haben – einen Vorsprung beim Erstellen einer statisch generierten Blog-Site verschaffen soll. ("Statically generated" bedeutet, dass unser Code in .html-Dateien kompiliert wird, die überall im Web bereitgestellt werden können. Dies ist einer von mehreren Ansätzen, die im "Jamstack"-Ansatz für die Erstellung von Websites enthalten sind.)

Und keine Sorge, wenn Sie nichts über SvelteKit wissen – dies dient nur zur Demonstration, und wir werden nichts schreiben, was Sie nicht bereits kennen. Dennoch ist es erwähnenswert, dass SvelteKit Vite im Hintergrund verwendet, das tatsächlich ein Npm-Paket ist und uns Zugriff auf moderne Build-Tools und einen superschnellen Entwicklungsserver gibt.

Klonen des Projekts

Zuerst müssen wir das Projekt "klonen", was ein schickes Wort dafür ist, das Projekt auf unser System zu kopieren, damit wir es lokal bearbeiten können. Es gibt zwei Möglichkeiten, ein bestehendes Projekt zu klonen.

Wenn Sie die visuelle In-Browser-Methode bevorzugen, gehen Sie zum Starter-Repository auf GitHub, klicken Sie auf das Dropdown "Code", das sich direkt in der GitHub-Oberfläche befindet, und wählen Sie die Option "Download ZIP".

Alternativ können Sie, wenn Sie lieber die Kommandozeile verwenden möchten, diesen Befehl ausführen (stellen Sie einfach sicher, dass Sie sich an einem Ort befinden, an dem es Ihnen nichts ausmacht, einen neuen Projektordner auf Ihrem Computer anzulegen, z. B. cd /pfad/zum/ordner)

npx degit https://github.com/josh-collinsworth/sveltekit-blog-starter.git sveltekit-blog-starter

Sie erinnern sich vielleicht, dass npx es uns ermöglicht, Npm-Pakete auszuführen, ohne sie dauerhaft zu installieren. degit klont das Projekt genauso wie git clone, aber ohne dessen Git-Historie (buchstäblich "de-git").

Welche Methode Sie auch immer verwenden, Sie erhalten einen frischen neuen Ordner sveltekit-blog-starter. Öffnen wir ihn in einem Code-Editor, öffnen wir das Terminal und führen Sie den Befehl npm install (oder npm i) aus.

An dieser Stelle sehen Sie einen Hinweis auf Schwachstellen, wie wir ihn im letzten Abschnitt dieses Leitfadens behandelt haben. Möglicherweise steht dort etwas wie "0 Schwachstellen gefunden" (wie im obigen Screenshot), aber es ist gut möglich, dass diese Zahl größer als Null ist. Wenn Sie Schwachstellen sehen, machen Sie sich keine Sorgen. Sie können sie vorerst ignorieren, da dies kein Projekt ist, das wir in der Produktion starten wollen, damit es andere sehen oder nutzen können. (Weitere Informationen finden Sie im Abschnitt über npm audit in einem früheren Kapitel.)

Starten des Servers und Vornehmen von Änderungen

Wenn Sie einen Blick in die Datei package.json des geklonten Projekts werfen würden, sähen Sie den Befehl zum Starten des Dev-Servers

npm run dev

Führen Sie diesen Befehl im Terminal aus, und Sie sollten fast sofort etwas Ähnliches wie das Folgende sehen

In VS Code können Sie CMD drücken und auf die URL https://:3000 klicken oder sie manuell in Ihren Browser eingeben. In jedem Fall sollte die Website im Browser angezeigt werden!

Nehmen wir uns hier einen Moment Zeit, um zu würdigen, wie relativ schnell und einfach das war! Ja, wir mussten vielleicht zuerst eine Menge Gerüst installieren, aber das ist ein einmaliger Aufwand. Wir haben ein ganzes Projekt mit nur ein paar Befehlen auf unserer Maschine am Laufen – und das Gleiche können wir jederzeit tun, wenn wir ein weiteres bestehendes Projekt installieren wollen!

Ich werde nicht ins Detail dieses speziellen Projekts gehen, da es für das Erlernen von Npm unwichtig ist, aber es ist ein schönes Beispiel, da es viele cool konfigurierte Dinge enthält und wir leicht Änderungen vornehmen und sehen können, wie sie im Browser sofort aktualisiert werden. Sehen wir uns als Nächstes einige dieser Befehle an.

SvelteKit benötigt Node 14 oder höher. Wenn Sie Npm im Rahmen dieses Leitfadens installiert haben, ist das kein Problem für Sie. Aber wenn Sie es bereits vor Beginn installiert hatten und auf Fehler stoßen, wenn Sie dieses Projekt zum Laufen bringen wollen, lohnt es sich, schnell node -v zu überprüfen, um sicher zu sein. Nvm ist Ihr Freund, wenn Sie ein Upgrade benötigen.

Sass beim Speichern automatisch kompilieren

Sie finden die Sass-Dateien des Projekts im Ordner src/lib/assets/scss/. Versuchen Sie, die Datei global.scss direkt zu öffnen. Nehmen Sie eine Änderung vor, speichern Sie sie, und Sie sollten die Aktualisierung automatisch (und fast *sofort*) in Ihrem Browser sehen.

Inhaltsänderungen vornehmen

Die Starter-Site verwendet tatsächlich die README.md-Datei des Repos als Homepage. Wenn Sie README.md öffnen und Änderungen vornehmen (es ist in Ordnung, wenn Sie Markdown nicht kennen, jede Bearbeitung reicht aus), sollten Sie diese Änderungen sofort nach dem Speichern sehen, genau wie Sass im letzten Schritt

Wenn Sie möchten, können Sie eine andere Seite öffnen, z. B. die Datei src/routes/contact.svelte, und das HTML aktualisieren, um zu sehen, wie es im Browser live aktualisiert wird, sobald es gespeichert wird.

Sie können sogar eine der Markdown-Dateien unter src/lib/posts/ duplizieren und Änderungen vornehmen, um zu sehen, dass sie automatisch in der Liste der Beiträge auf der Seite /blog erscheint, wenn Sie das möchten. (Stellen Sie nur sicher, dass Sie ihr einen eindeutigen Titel geben.)

Imports verstehen

Es gibt eine wichtige Sache bei Npm-Projekten, die wir im vierten Kapitel kurz erwähnt haben, aber noch nicht behandelt haben: Imports. Dieser Leitfaden wäre nicht wirklich vollständig, wenn wir das nicht ansprechen würden. Die Grundidee ist, dass wir – getreu dem Namen – ein Paket in unserem Code importieren und es sofort verwenden können.

Wie das geht? Öffnen Sie die Datei svelte.config.js im Projektstammverzeichnis, und Sie sehen oben einen Block mit import-Zeilen, etwa so:

import adapter from '@sveltejs/adapter-static'
import { mdsvex } from 'mdsvex'
import preprocess from 'svelte-preprocess'
import rehypeAutolinkHeadings from 'rehype-autolink-headings'
import rehypeSlug from 'rehype-slug'

Jeder dieser imports ist ein installiertes Paket, das in dieser Datei verwendet wird. Was jedes Paket tatsächlich tut, ist im Moment nicht wichtig; ich möchte nur auf die import-Syntax aufmerksam machen. So verwenden wir Pakete *in unseren tatsächlichen Code-Dateien*; wir sagen JavaScript, *was* es importieren soll und *woher*. Dann können wir es in unserem Code aufrufen.

Diese Syntax wird "ES6 Imports" genannt, und es ist nur *wichtig* (verstehen Sie?!), das zu wissen, weil es der Standard ist, auf den sich sowohl browserbasierte JavaScript als auch Node-JavaScript für die zukünftige Verwendung geeinigt haben.

Zuvor verwendete Node-JavaScript (und verwendet oft immer noch) eine etwas andere Syntax namens CommonJS. Wenn Sie einen Import sehen, der so aussieht, handelt es sich um den alten CommonJS-Stil

const myPackage = require('package-name')

Das andere entscheidende, was man über den ES6-Importstil verstehen muss, ist: Die Syntax ist Npm-spezifisch, kein Sprachstandard.

Um es klar auszudrücken: Sie *können* import in normalem JavaScript verwenden. Es ist eine sehr übliche Funktion der Sprache, eine Variable, Funktion, ein Objekt usw. aus einer Datei zu exportieren und sie dann zu importieren, um sie in einer anderen zu verwenden. Aber um das zu tun, müssen Sie einen relativen Pfad oder (in moderneren Browsern) eine URL zu dem, was Sie importieren, angeben. Nur die Verwendung eines Strings mit dem Namen eines Pakets, wie wir ihn hier sehen, ist nicht gültig.

Warum wird er also verwendet, wenn er technisch kein gültiger Code ist? Weil die Handhabung dieser Importart eine der netten Dinge ist, die Npm für uns erledigt. Wenn wir Npm anweisen, import somePackage from 'name' als String ohne Pfad zu verwenden, weiß Npm automatisch, dass es die installierten Pakete im Projekt durchsuchen soll, um den angeforderten Import zu finden. Das erspart uns sowohl das Tippen langwieriger relativer Pfade als auch die Notwendigkeit, tatsächlich zu wissen, wo unsere Pakete tief im Labyrinth von node_modules liegen.

Das mag offensichtlich sein, aber: Da die Syntax nicht gültig ist, können Sie sie nicht erfolgreich verwenden, es sei denn, Ihr Npm-Projekt enthält einen Bundler oder Compiler irgendeiner Art, um die Imports und Module in gültigen Browsercode zu verarbeiten.

Erstellen der finalen Website

Die meisten Npm-Projekte dieser Art haben zwei Hauptzwecke

1. Hilfe bei der Entwicklung Ihrer Website oder App
2. Erstellen einer finalen Produktionsversion

SvelteKit ist da keine Ausnahme. Wenn wir mit unserer (fantastischen) Entwicklungsserver-Einrichtung fertig sind und mit unseren Änderungen zufrieden sind, können wir diesen Befehl ausführen

npm run build

Wenn Ihr Entwicklungsserver noch läuft, können Sie ihn entweder mit Ctrl+C beenden oder einen neuen Terminal-Tab öffnen. Sie können keine Befehle in demselben Terminalfenster eingeben, in dem der Entwicklungsprozess läuft, da dies eine aktive, fortlaufende Aufgabe ist.

Wenn wir den Befehl build ausführen, verarbeitet SvelteKit alle Dateien im Projekt und gibt eine vollständig gebündelte, bereit zur Bereitstellung Sammlung von statischen HTML-, CSS- und JavaScript-Dateien aus, und das recht schnell. Sie könnten diese Sammlung von Dateien überall hochladen, wo Sie eine Website hosten können. Moderne Tools; gute alte Ausgabe.

Wenn der Build-Befehl abgeschlossen ist, sollten Sie einen neuen Ordner build im Stammverzeichnis (d. h. auf der obersten Ebene) Ihres Projektordners sehen. Wenn Sie ihn durchsehen, werden Sie feststellen, dass es keine .md, .svelte oder andere Dateien mehr gibt, die ein Browser nicht lesen kann. Alles wurde in reines HTML, CSS und JavaScript kompiliert, ganz zu schweigen davon, dass – wie Sie sehen werden, wenn Sie eine JavaScript- oder CSS-Datei öffnen – diese gründlich minimiert sind, um so *klein* wie möglich zu sein, damit sie im Browser so *schnell* wie möglich geladen werden.

Wenn Sie möchten, können Sie npm run preview ausführen, nachdem der Build abgeschlossen ist, um zu sehen, wie die kompilierte Website im Browser geladen wird. Der Unterschied hier ist, dass die Inhalte aus dem finalen Ordner build geladen werden, anstatt wie beim Befehl dev dynamisch mit vorkompilierten Dateien erstellt zu werden. Sie werden keinen Unterschied *sehen*, es sei denn, Sie öffnen die Netzwerk-Registerkarte in DevTools (oder versuchen, etwas zu aktualisieren), aber Sie werden das Endprodukt sehen.

Dies ist ein optionaler Schritt, aber ich finde es ziemlich cool, eine Vorstellung davon zu bekommen, wie wenige kompilierte Dateien wir am Ende haben, angesichts all der verschiedenen Dateien, die wir in das Projekt gesteckt haben, und wie winzig das finale Bundle tatsächlich ist, dank der erstaunlichen Build-Tools, die in diesem Projekt integriert sind. (Zur Information, es ist alles SvelteKit und Vite.)

Moderne Deployment-Praktiken

Das ist ein Thema für ein anderes Mal, aber modernes Deployment erfordert oft nicht, dass Sie einen build-Befehl ausführen und die Dateien selbst hochladen (obwohl das immer noch eine Option ist). Stattdessen verbindet sich ein Hoster (wie Netlify oder Vercel) direkt mit dem GitHub-Repo Ihres Projekts und führt jedes Mal, wenn Sie Änderungen an den Hauptzweig des Repos pushen, Ihren Build-Befehl aus und stellt die kompilierten Dateien automatisch bereit!

Das ist eines der vielen äußerst angenehmen Features dieser neuen Ära der Frontend-Entwicklung. Kein Herumfummeln mit FTP oder manuelles Ziehen von Dateien irgendwohin; wir sind zuversichtlich, dass alles automatisch erstellt und bereitgestellt wird, wenn wir unseren Code pushen, ohne dass wir etwas tun müssen!

Abschluss dieses Npm-Leitfadens

Wenn Sie es bis hierher geschafft haben, herzlichen Glückwunsch! Und danke. Herzlichen Glückwunsch, denn das war eine lange, *lange* Lektüre. Und danke, denn… nun ja, es war eine lange, *lange* Lektüre.

Aber Sie haben es geschafft und hoffentlich auch wichtige Dinge gelernt. Ich erwähnte am Anfang, dass mein Ziel nicht Kürze, sondern Effektivität war. Das bedeutet, wir haben *viel* abgedeckt. Wir begannen mit einem kurzen Überblick über Npm und seinen Platz in der modernen Frontend-Entwicklungslandschaft, bevor wir uns mit der Kommandozeile vertraut machten. Von dort aus zerlegten wir die Begriffe "Node" und "Paketmanager", um ein präzises Verständnis dafür zu bekommen, was Npm ist und was es tut. Sobald wir uns mit der Rolle von Paketmanagern in der Entwicklung vertraut gemacht hatten, tauchten wir direkt in Npm ein, einschließlich wie man es installiert, Pakete zu einem Projekt hinzufügt, Befehle einrichtet und schließlich, wie man in ein bestehendes Projekt einsteigt, das Npm verwendet.

Ich hoffe, dass alles, was wir in diesem Npm-Leitfaden behandelt haben, zumindest die Tür weit genug öffnet, damit Sie Npm weiter erkunden und sich weiterentwickeln können, wenn Sie bereit sind. Oft muss ich etwas viele Male wiederholen und mehrere Ansätze ausprobieren, damit etwas wirklich einsinkt. Wenn Sie also dasitzen und sich fast so verwirrt fühlen wie zuvor, nehmen Sie sich mehr Zeit dafür. Reflektieren Sie darüber, was Sie wissen und was Sie gelernt haben, und kommen Sie zurück – oder versuchen Sie einen neuen Ansatz, wenn Sie bereit sind!

Kapitel des Leitfadens

1. Für wen ist diese Anleitung?
2. Was zum Teufel bedeutet „npm“?
3. Was zum Teufel ist die Befehlszeile?
4. Was zum Teufel ist Node?
5. Was zum Teufel ist ein Paketmanager?
6. Wie zum Teufel installiert man npm?
7. Wie zum Teufel installiert man npm-Pakete?
8. Was zum Teufel sind npm-Befehle?
9. Wie zum Teufel installiert man ein bestehendes Npm-Projekt? (Sie sind hier!)