4탄이 마지막이 될 것 같다.
앞선 3탄에 비해서는 많이 쓰이는 것들은 아닌것 같지만 그래도 한번 알고 가면 좋을것이다.
https://docs.npmjs.com/cli/v8/configuring-npm/package-json npm 공식문서를 읽으며 번역하여 기록해두기로 한다.
overrides
overrides
If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override.
Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. These changes can be scoped as specific or as vague as desired.
To make sure the package foo is always installed as version 1.0.0 no matter what version your dependencies rely on:
{
"overrides": {
"foo": "1.0.0"
}
}
The above is a short hand notation, the full object form can be used to allow overriding a package itself as well as a child of the package. This will cause foo to always be 1.0.0 while also making bar at any depth beyond foo also 1.0.0:
{
"overrides": {
"foo": {
".": "1.0.0",
"bar": "1.0.0"
}
}
}
To only override foo to be 1.0.0 when it's a child (or grandchild, or great grandchild, etc) of the package bar:
{
"overrides": {
"bar": {
"foo": "1.0.0"
}
}
}
Keys can be nested to any arbitrary length. To override foo only when it's a child of bar and only when bar is a child of baz:
{
"overrides": {
"baz": {
"bar": {
"foo": "1.0.0"
}
}
}
}
The key of an override can also include a version, or range of versions. To override foo to 1.0.0, but only when it's a child of bar@2.0.0:
{
"overrides": {
"bar@2.0.0": {
"foo": "1.0.0"
}
}
}
You may not set an override for a package that you directly depend on unless both the dependency and the override itself share the exact same spec. To make this limitation easier to deal with, overrides may also be defined as a reference to a spec for a direct dependency by prefixing the name of the package you wish the version to match with a $.
{
"dependencies": {
"foo": "^1.0.0"
},
"overrides": {
// BAD, will throw an EOVERRIDE error
// "foo": "^2.0.0"
// GOOD, specs match so override is allowed
// "foo": "^1.0.0"
// BEST, the override is defined as a reference to the dependency
"foo": "$foo",
// the referenced package does not need to match the overridden one
"bar": "$foo"
}
}
오버라이드
종속성의 종속성을 특정하게 변경해야 하는 경우, 예를 들어 알려진 보안문제가 있는 종속성 버전 교체, 기존 종속성을 fork로 교체 또는 동일한 버전의 패키지가 모든 곳에서 사용되는지확인 등 재정의를 추가할수 있다.
재정의는 종속성 트리의 패키지를 다른 버전 또는 완전히 다른 패키지로 바꾸는 방법을 제공한다. 이러한 변경 사항은 원하는 대로 구체적이거나 모호한 범위로 지정할 수 있다.
{
"overrides": {
"foo": "1.0.0"
}
}
위의 내용은 짧은 표기법이며 전체 개체 형식을 사용하여 패키지 자체와 패키지의 자식을 재정의할 수 있다. 이렇게 하면 foo가 항상 1.0.0이 되는 동시에 bar가 foo를 넘어도 1.0.0이 된다.
{
"overrides": {
"foo": {
".": "1.0.0",
"bar": "1.0.0"
}
}
}
foo가 패키지 막대의 자식인 경우에만 foo를 1.0.0ㅐ으로 재정의 하려면 다음을 수행한다.
{
"overrides": {
"bar": {
"foo": "1.0.0"
}
}
}
키는 임의의 길이로 중첩될 수 있다. foo가 bar의 자식이고 bar가 baz의 자식일 때만 재정의 하려면:
{
"overrides": {
"baz": {
"bar": {
"foo": "1.0.0"
}
}
}
}
재정의 키에는 버전 또는 버전 범위도 포함될 수 있다. foo를 1.0.0으로 재정의 하려면 bar@2.0.0의 자식인 경우에만:
{
"overrides": {
"bar@2.0.0": {
"foo": "1.0.0"
}
}
}
종속성과 재정의 자체가 정확히 동일한 사양을 공유하지 않는한 직접 의존하는 패키지에 대한 재정의를 설정할 수 없다. 이 제한을 더 쉽게 처리하기 위해 재정의는 버전과 일치시키려는 패키지 이름 앞에 $를 추가하여 직접 종속성에 대한 사양에 대한 참조로 정의할 수도 있다.
{
"dependencies": {
"foo": "^1.0.0"
},
"overrides": {
// BAD, will throw an EOVERRIDE error
// "foo": "^2.0.0"
// GOOD, specs match so override is allowed
// "foo": "^1.0.0"
// BEST, the override is defined as a reference to the dependency
"foo": "$foo",
// the referenced package does not need to match the overridden one
"bar": "$foo"
}
}
engines
engines
You can specify the version of node that your stuff works on:
{
"engines": {
"node": ">=0.10.3 <15"
}
}
And, like with dependencies, if you don't specify the version (or if you specify "*" as the version), then any version of node will do.
You can also use the "engines" field to specify which versions of npm are capable of properly installing your program. For example:
{
"engines": {
"npm": "~1.0.20"
}
}
Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.
엔진
작동하는 노드의 버전을 지정 할 수 있다.
{
"engines": {
"node": ">=0.10.3 <15"
}
}
그리고 종속성과마찬가지로 버전을 지정하지 않으면 노드의 모든 버전이 수행된다.
"engines" 필드를 사용하여 프로그램을 제대로 설치할 수 있는 npm 버전을 지정할 수도 있다. 예를 들어:
{
"engines": {
"npm": "~1.0.20"
}
}
사용자가 engine-strict 구성 플래그를 설정하지 않은 경우 이 필드는 권고 사항일 뿐이며, 패키지가 종속 항목으로 설치될 때만 경고를 생성한다.
os
os
You can specify which operating systems your module will run on:
{
"os": [
"darwin",
"linux"
]
}
You can also block instead of allowing operating systems, just prepend the blocked os with a '!':
{
"os": [
"!win32"
]
}
The host operating system is determined by process.platform
It is allowed to both block and allow an item, although there isn't any good reason to do this.
os
모듈이 실행될 운영체제를 지정할 수 있다.
{
"os": [
"darwin",
"linux"
]
}
운영체제를 허용하는 대신 차단할 수도 있다. 차단된 운영체제 앞에 '!'를 추가하면 된다.
{
"os": [
"!win32"
]
}
호스트 운영체제는 process.platform에 의해 결정된다.
항몽을 차단하거나 허용할 수 있지만 그럴 이유가 없다.
cpu
cpu
코드가 특정 CPU 아키텍처에서만 실행되는 경우 어떤 아키텍처를 지정할수 있다.
{
"cpu": [
"x64",
"ia32"
]
}
os 옵션과 마찬가지로 아키텍처를 차단할 수도 있다
{
"cpu": [
"!arm",
"!mips"
]
}
호스트 아키텍처는 process.arch에 의해 결정된다.
private
private
If you set "private": true in your package.json, then npm will refuse to publish it.
This is a way to prevent accidental publication of private repositories. If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the publishConfig dictionary described below to override the registry config param at publish-time.
private
package.json에서 "private": ture를 설정하면 npm이 게시를 거부한다.
이는 개인 레포지토리가 실수로 게시되는 것을 방지하는 방법이다. 지정된 패키지가 특정 레지스트리에만 게시되도록 하려면 아래 설명된 publishConfig 사전을 사용하여 게시 시 레지스트리 구성 매개변수를 재정의한다.
publishConfig
publishConfig
This is a set of config values that will be used at publish-time. It's especially handy if you want to set the tag, registry or access, so that you can ensure that a given package is not tagged with "latest", published to the global public registry or that a scoped module is private by default.
See config to see the list of config options that can be overridden.
publishConfig
이것은 게시할떄 사용될 구성 값 세트이다. 태그, 레지스트리 또는 액세스를 설정하려는 경우 특히 우용하므로 주어진 패키지가 "최신" 태그가 지정되지 않았는지, 전역 공개 레지스트리에 게시되었는지 또는 범위가 지정된 모듈이 기본적으로 비공개인지 확인할 수 있다.
재정의할 수 있는 config 옵션 목록을 보려면 config를 참조하여라.
workspaces
workspaces
The optional workspaces field is an array of file patterns that describes locations within the local file system that the install client should look up to find each workspace that needs to be symlinked to the top level node_modules folder.
It can describe either the direct paths of the folders to be used as workspaces or it can define globs that will resolve to these same folders.
In the following example, all folders located inside the folder ./packages will be treated as workspaces as long as they have valid package.json files inside them:
{
"name": "workspace-example",
"workspaces": [
"./packages/*"
]
}
See workspaces for more examples.
workspaces
선택적 작업 영역 필드는 설치 클라이언트가 최상위 수준 node_modules폴더에 심볼릭 링크되어야 하는 각 작업 영역을 찾기 위해 조회해야 하는 로컬 파일 시스템 내의 위치를 설명하는 파일 패턴의 배열이다.
작업 공간으로 사용할 폴더의 직접 경로를 설명하거나 동일한 폴더로 확인되는 glob을 정의할 수 있다.
다음의 예에서 ./packages 폴더 안에 있는 모든 폴더는 내부에 유효한 package.json 파일이 있는 한 작업 공간으로 취급된다.
{
"name": "workspace-example",
"workspaces": [
"./packages/*"
]
}
더 많은 예제는 workspaces 을 참조하여라.
DEFAULT VALUES
DEFAULT VALUES
npm will default some values based on package contents.
- "scripts": {"start": "node server.js"}
- If there is a server.js file in the root of your package, then npm will default the start command to node server.js.
- "scripts":{"install": "node-gyp rebuild"}
- If there is a binding.gyp file in the root of your package and you have not defined an install or preinstall script, npm will default the install command to compile using node-gyp.
- "contributors": [...]
- If there is an AUTHORS file in the root of your package, npm will treat each line as a Name <email> (url) format, where email and url are optional. Lines which start with a # or are blank, will be ignored.
DEFAULT VALUES
npm은 패키지 내용에 따라 일부 값을 기본 값으로 설정한다.
- "scripts": {"start": "node server.js"}
- 패키지의 루트에 server.js 파일이 있는 경우 npm은 시작 명령을 node server.js로 기본 설정한다.
- "scripts":{"install": "node-gyp rebuild"}
- 패키지 루트에 binding.gyp 파일이 있고 설치 또는 사전 설치 스크립트를 정의하지 않은 경우 npm은 기본 설치 명령을 node-gyp를 사용하여 컴파일 한다.
- "contributors": [...]
- 패키지의 루트에 AUTHORS 파일이 있는 경우 npm은 각 줄을 Name <email>(url) 형식으로 처리한다. 여기서 email과 url은 선택 사항이다. #으로 시작하거나 비어있는 행은 무시된다.
'NodeJS > NodeJS' 카테고리의 다른 글
[NodeJS] 공식문서와 함께하는 package.json에 대한 모든 것 3탄 (1) | 2023.01.21 |
---|---|
[NodeJS] 공식문서와 함께하는 package.json에 대한 모든 것 2탄 (0) | 2023.01.17 |
[NodeJS] request모듈의 qs에 Object.assign 사용하여 배열넣기 (0) | 2022.12.19 |
[NodeJS] 공식문서와 함께하는 package.json에 대한 모든 것 1탄 (0) | 2022.11.21 |
[NVM] nvm 설치하기 (0) | 2022.09.22 |