Laden Sie „npm run dev' mit package.json-Skripten auf

npm run dev ist der Standard für „meine Website lokal ausführen“, aber wie funktioniert es? Wie können wir seine Funktionalität erweitern? In diesem Beitrag schauen wir uns Folgendes an:

• So konfigurieren Sie, was npm run dev tut.
• Wie man komplexe Befehle in granulare Einheiten zerlegt.
• So führen Sie mehrere Befehle parallel aus.
• So führen Sie die Voraussetzungen aus, ohne das normale Strg-C-Verhalten zu verlieren.
• So fügen Sie Seed-Daten hinzu (falls keine vorhanden sind), wenn Sie ein Convex-Backend starten.

Als motivierendes Beispiel finden Sie hier einige Skripte, die in der Beispiel-App „convex-helpers“ definiert sind. Wir besprechen, was die einzelnen Teile bewirken

  "scripts": {
    "dev": "npm-run-all --parallel dev:backend dev:frontend",
    "build": "tsc && vite build",
    "dev:backend": "convex dev",
    "dev:frontend": "vite",
    "predev": "convex dev --until-success",
    "test": "vitest"
  },

Wie und wo sie definiert sind

npm run führt Befehle aus, die in Ihrer package.json im Arbeitsbereich Ihres Projekts definiert sind. Diese Befehle sind oft vorkonfiguriert, wenn Sie Ihr Repo über einen Befehl wie npm create vite@latest mit Befehlen für:

starten

• dev: Führen Sie eine Entwicklungsumgebung aus. Dazu gehört häufig das automatische Neuladen der Benutzeroberfläche, wenn sich Dateien ändern. Für Vite ist dies vite und Next.js ist next dev.
• Build: Erstellen Sie die Website für die Bereitstellung. Dadurch werden im Allgemeinen alle Ihre HTML-, CSS- und Javascript-Dateien kompiliert und gebündelt. Für Vite ist dies der Vite-Build und Next.js ist der nächste Build.
• test: Führen Sie Tests aus – wenn Sie Jest verwenden, ist es nur „test“: „jest“ oder vitest für Vitest.

Hier ist ein einfaches Beispiel von Next.js:

// in package.json
{
// ...
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
//...

Hier können Sie npm run dev oder npm run lint usw. ausführen.

Mehr über npm run erfahren Sie in den Dokumenten.

Warum Skripte verwenden?

Es ist eine berechtigte Frage, warum man Befehle, die ohnehin schon so einfach sind, in Paketskripte integrieren sollte. Warum nicht einfach Jest oder Vite oder Next Build anrufen? Es gibt ein paar gute Gründe:

1. Sie können die Standardparameter für Befehle speichern, sodass Sie sich nicht die „Standard“-Methode zum Starten von etwas merken oder dokumentieren müssen. Unten sehen wir, wie Sie es so konfigurieren können, dass Befehle verkettet und andere parallel ausgeführt werden.
2. Es ermöglicht Ihnen die einfache Ausführung von Befehlen, die von npm installiert werden, aber nicht global über Ihre Shell (Terminal) zugänglich sind.¹ Wenn Sie Dinge wie npm install -D vitest installieren, wird vitest in node_modules/ installiert. .bin.² Sie können vitest nicht direkt in Ihrer Shell ausführen,³ aber Sie können eine Konfiguration wie: "scripts": { "test": "vitest" } und haben npm run test führt vitest aus.
3. Es läuft immer mit dem Stammverzeichnis des Paketordners als „aktuelles Verzeichnis“, auch wenn Sie sich in einem Unterverzeichnis befinden. Sie können also ein Skript wie „foo“ definieren: „./myscript.sh“ und es sucht immer nach myscript.sh im Paketstammverzeichnis (im selben Verzeichnis wie package.json). Hinweis: Sie können über die Umgebungsvariable INIT_CWD auf das aktuelle Verzeichnis zugreifen, in dem es aufgerufen wurde.
4. Sie können problemlos auf Variablen in package.json verweisen, wenn das Skript über npm run ausgeführt wird. Sie können beispielsweise mit der Umgebungsvariablen npm_package_version auf die „Version“ Ihres Pakets zugreifen, z. B. „process.env.npm_package_version“ in js oder „$npm_package_version“ in einem Skript.
5. Wenn Sie mehrere Arbeitsbereiche haben (viele Verzeichnisse mit ihrer eigenen package.json, die in einer übergeordneten package.json mit einer „workspaces“-Konfiguration konfiguriert ist), können Sie den gleichen Befehl in allen Arbeitsbereichen mit npm test --workspaces oder einem mit ausführen npm run lint --workspace apps/web.

Funktioniert npm run dev mit Yarn/pnpm/bun?

Ja! Selbst wenn Sie Ihre Abhängigkeiten mit einem anderen Paketmanager installieren, können Sie Ihre Paketskripte weiterhin mit npm ausführen.

yarn # similar to `npm install`
npm run dev # still works!

Sie müssen sich nicht daran erinnern, dass „npm run dev“ auf „garn dev“ (oder „garn run dev“) abgebildet wird. Das Gleiche gilt für npx: npx convex dev funktioniert unabhängig davon, welchen Paketmanager Sie zur Installation verwendet haben.

Befehle parallel ausführen

Es gibt ein paar Pakete, mit denen Sie Befehle gleichzeitig ausführen können:⁴

1. npm-run-all
2. gleichzeitig

Wir schauen uns hier nur npm-run-all an. Betrachten Sie unser Beispiel:

  "scripts": {
    "dev": "npm-run-all --parallel dev:backend dev:frontend",
    "dev:backend": "convex dev",
    "dev:frontend": "vite",
  },

Dies definiert drei Skripte.

1. npm run dev:backend führt convex dev aus.
2. npm run dev:frontend führt vite aus.
3. npm run dev führt sowohl convex dev als auch vite parallel über npm-run-all aus.

Beide Ausgaben werden gestreamt und durch Drücken von Strg-C werden beide Skripte unterbrochen.

predev? Postbuild?

Sie können Befehle angeben, die vor (pre) oder nach (post) einem anderen Befehl (z. B. X) ausgeführt werden sollen, indem Sie Ihren Befehl preX oder postX nennen. Im Beispiel:

  "scripts": {
    "dev": "npm-run-all --parallel dev:backend dev:frontend",
    "dev:backend": "convex dev",
    "dev:frontend": "vite",
    "predev": "convex dev --until-success",
  },

Dadurch wird convex dev --until-success vor dem „dev“-Befehl von npm-run-all --parallel dev:backend dev:frontend ausgeführt.

Chaining with "&&"

For those used to shell scripting, you can run two commands in sequence if the previous one succeeds with commandA && commandB. This works on both Windows and Unix (mac / linux).

However, there's a couple advantages to just using pre-scripts:

1. You can run either command with npm run dev --ignore-scripts to not do the "predev" script, or npm run predev to explicitly only do the "predev" step.
2. The Ctrl-C behavior is more predictable in my experience. In different shell environments, doing Ctrl-C (which sends an interrupt signal to the current process) would sometimes kill the first script but still run the second script. After many attempts we decided to switch to "predev" as the pattern.

Run interactive steps first

For Convex, when you first run npx convex dev (or npm run dev with the above scripts), it will ask you to log in if you aren't already, and ask you to set up your project if one isn't already set up. This is great, but interactive commands that update the output text don't work well when the output is being streamed by multiple commands at once. This is the motivation for running npx convex dev --until-success before npx convex dev.

• convex dev syncs your functions and schema whenever it doesn't match what you have deployed, watching for file changes.
• The --until-success flag syncs your functions and schema only until it succeeds once, telling you what to fix if something is wrong and retrying automatically until it succeeds or you Ctrl-C it.
• By running npx convex dev --until-success, we can go through the login, project configuration, and an initial sync, all before trying to start up the frontend and backend.
• The initial sync is especially helpful if it catches issues like missing environment variables which need to be set before your app can function.
• This way the frontend doesn't start until the backend is ready to handle requests with the version of functions it expects.

Seeding data on startup

If you change your "predev" command for Convex to include --run it will run a server-side function before your frontend has started.

  "scripts": {
      //...
    "predev": "convex dev --until-success --run init",
        //...
  },

The --run init command will run a function that is the default export in convex/init.ts. You could also have run --run myFolder/myModule:myFunction. See docs on naming here. See this post on seeding data but the gist is that you can define an internalMutation that checks if the database is empty, and if so inserts a collection of records for testing / setup purposes.

tsc?

If you use TypeScript, you can run a type check / compile your typescript files with a bare tsc. If your tsconfig.json is configured to emit types, it will write out the types. If not, it will just validate the types. This is great to do as part of the build, so you don't build anything that has type errors. This is why the above example did:

    "build": "tsc && vite build",

How to pass arguments?

If you want to pass arguments to a command, for instance passing arguments to your testing command to specify what test to run, you can pass them after a -- to separate the command from the argument. Technically you don't need -- if your arguments are positional instead of --prefixed, but it doesn't hurt to always do it in case you forget which to do it for.

npm run test -- --grep="pattern"

Summary

We looked at some ways of using package.json scripts to simplify our workflows. Who knew how much power could rest behind a simple npm run dev? Looking at our original example:

  "scripts": {
    "dev": "npm-run-all --parallel dev:backend dev:frontend",
    "build": "tsc && vite build",
    "dev:backend": "convex dev",
    "dev:frontend": "vite",
    "predev": "convex dev --until-success",
    "test": "vitest"
  },

• dev runs the frontend and backend in parallel, after predev.
• build does type checking via tsc before building the static site.
• dev:backend continuously deploys the backend functions to your development environment as you edit files.
• dev:frontend runs a local frontend server that auto-reloads as you edit files.
• predev runs before dev and does an initial deployment, handling login, configuration, and an initial sync as necessary.
• test uses Vitest to run tests. Note: npm test is shorthand for npm run test along with other commands, but they're special cases. npm run test is the habit I suggest.

---

1. The way your shell finds which command to run when you type npm is to check the shell's PATH environment variable (on unix machines anyways). You can see your own with echo "$PATH". It checks all the places specified in $PATH and uses the first one.  ↩

2. Technically you can override & specify where npm installs binaries. ↩

3. Wenn Sie wirklich möchten, können Sie npm exec vitest, kurz npx vitest, ./npm_modules/.bin/vitest direkt ausführen oder .npm_modules/.bin zu Ihrem PATH hinzufügen. ↩

4. Manche Leute verwenden ein bloßes &, um eine Aufgabe im Hintergrund auszuführen, aber das wird unter Windows nicht unterstützt, und das Unterbrechen eines Befehls führt nicht unbedingt zum Abbruch des anderen. ↩

Das obige ist der detaillierte Inhalt vonLaden Sie „npm run dev' mit package.json-Skripten auf. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!