package.json 스크립트로 'npm run dev' 성능 강화-JS 튜토리얼-php.cn

Supercharge `npm run dev` with package.json scripts

npm run dev는 "내 웹사이트를 로컬에서 실행"하는 표준인데 어떻게 작동하나요? 기능을 어떻게 확장할 수 있나요? 이 게시물에서 살펴볼 내용은 다음과 같습니다.

npm run dev의 기능을 구성하는 방법
복잡한 명령을 세분화된 단위로 분해하는 방법
여러 명령을 병렬로 실행하는 방법
일반적인 Ctrl-C 동작을 잃지 않고 필수 구성 요소를 실행하는 방법
Convex 백엔드를 시작할 때 시드 데이터(존재하지 않는 경우)를 추가하는 방법

동기 부여의 예로, 다음은 볼록 도우미 예제 앱에 정의된 몇 가지 스크립트입니다. 각 작품이 어떤 역할을 하는지 살펴보겠습니다

  "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"
  },

로그인 후 복사

정의 방법 및 위치

npm run은 프로젝트 작업공간의 package.json에 정의된 명령을 실행합니다. 이러한 명령은 다음 명령을 사용하여 npm create vite@latest와 같은 명령으로 저장소를 시작할 때 사전 구성되는 경우가 많습니다.

dev: 개발 환경을 실행합니다. 여기에는 파일이 변경될 때 UI를 자동으로 다시 로드하는 작업이 포함되는 경우가 많습니다. Vite의 경우 이것은 vite이고 Next.js는 다음 개발자입니다.
build: 배포할 웹사이트를 구축합니다. 이는 일반적으로 모든 html, css 및 javascript를 컴파일하고 번들링합니다. Vite의 경우 이것은 vite 빌드이고 Next.js는 다음 빌드입니다.
테스트: 테스트 실행 - Jest를 사용하는 경우 Vitest의 경우 "test": "jest" 또는 vitest입니다.

다음은 Next.js의 기본 예입니다.

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

로그인 후 복사

여기에서 npm run dev 또는 npm run lint 등을 실행할 수 있습니다.

문서에서 npm run에 대해 자세히 알아볼 수 있습니다.

스크립트를 사용하는 이유는 무엇입니까?

이미 그렇게 간단한 명령을 패키지 스크립트에 넣는 이유는 정당한 질문입니다. 그냥 jest나 vite 또는 next build를 호출하면 안 되나요? 몇 가지 좋은 이유가 있습니다.

명령의 기본 매개변수를 저장할 수 있으므로 무언가를 시작하는 "표준" 방법을 기억하거나 문서화할 필요가 없습니다. 아래에서는 명령을 연결하고 다른 명령을 병렬로 실행하도록 구성하는 방법을 살펴보겠습니다.
npm으로 설치되었지만 쉘(터미널)에서 전역적으로 액세스할 수 없는 명령을 쉽게 실행할 수 있습니다.¹ npm install -D vitest와 같은 것을 설치하면 vitest가 node_modules/에 설치됩니다. .bin.² 셸에서 vitest를 직접 실행할 수는 없지만³ 다음과 같은 구성을 가질 수 있습니다: "scripts": { "test": "vitest" } npm run test는 vitest를 실행합니다.
하위 디렉터리에 있더라도 항상 패키지 폴더의 루트를 "현재 디렉터리"로 실행합니다. 따라서 "foo": "./myscript.sh"와 같은 스크립트를 정의하면 항상 패키지 루트(package.json과 동일한 디렉터리)에서 myscript.sh를 찾습니다. 참고: INIT_CWD 환경 변수를 통해 호출된 현재 디렉터리에 액세스할 수 있습니다.
npm run에서 스크립트를 실행할 때 package.json의 변수를 쉽게 참조할 수 있습니다. 예를 들어 js의 process.env.npm_package_version 또는 스크립트의 $npm_package_version과 같은 npm_package_version 환경 변수를 사용하여 패키지의 "버전"에 액세스할 수 있습니다.
여러 작업 공간("workspaces" 구성을 사용하여 상위 package.json으로 구성된 자체 package.json이 있는 많은 디렉터리)이 있는 경우 npm test --workspaces 또는 다음 중 하나를 사용하여 모든 작업 공간에서 동일한 명령을 실행할 수 있습니다. npm은 lint --workspace apps/web을 실행합니다.

npm run dev는 Yarn/pnpm/bun에서 작동하나요?

그렇습니다! 다른 패키지 관리자를 사용하여 종속성을 설치하더라도 npm을 사용하여 패키지 스크립트를 계속 실행할 수 있습니다.

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

로그인 후 복사

npm run dev가 Yarn dev(또는 Yarn Run dev)에 매핑된다는 점을 기억할 필요가 없습니다. npx도 마찬가지입니다. npx 볼록 개발은 설치에 사용한 패키지 관리자에 관계없이 작동합니다.

병렬로 명령 실행

명령을 동시에 실행하는 데 사용할 수 있는 몇 가지 패키지가 있습니다.⁴

npm-run-all
동시

여기에서는 npm-run-all을 살펴보겠습니다. 우리의 예를 생각해 보세요:

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

로그인 후 복사

이것은 세 가지 스크립트를 정의합니다.

npm run dev:backend는 볼록한 개발을 실행합니다.
npm run dev:frontend는 vite를 실행합니다.
npm run dev는 npm-run-all을 통해 Convex dev와 vite를 병렬로 실행합니다.

두 출력 모두 스트리밍되며 Ctrl-C를 누르면 두 스크립트가 모두 중단됩니다.

개발 전? 포스트빌드?

명령어 이름을 preX 또는 postX로 지정하여 다른 명령(예: X) 이전(사전) 또는 이후(사후)에 실행할 명령을 지정할 수 있습니다. 예에서:

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

로그인 후 복사

이렇게 하면 npm-run-all --parallel dev:backend dev:frontend의 "dev" 명령 이전에 convex dev --until-success가 실행됩니다.

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:

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.
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.

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. ↩
Technically you can override & specify where npm installs binaries. ↩
정말로 원한다면 npm exec vitest, 줄여서 npx vitest, ./npm_modules/.bin/vitest를 직접 실행하거나 PATH에 .npm_modules/.bin을 추가할 수 있습니다. ↩
어떤 사람들은 &를 사용하여 백그라운드에서 하나의 작업을 실행하지만 이는 Windows에서 지원되지 않으며 한 명령을 중단한다고 해서 반드시 다른 명령이 종료되는 것은 아닙니다. ↩

위 내용은 package.json 스크립트로 'npm run dev' 성능 강화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!