precaución, no utilice package.json para el nombre de la carpeta si desea clonar este proyecto en su máquina; se romperá yarn ( An unexpected error occurred: "EISDIR: illegal operation on a directory, read". ).
Versión original de este documento copiada de Yarnpkg.
Consulte también la documentación de npm, std-pkg, clean-publish, package-json-validator, cosmiconfig, rc (como un enfoque oponente a cosmiconfig).
nameversiondescriptionkeywordslicensehomepagebugsrepositoryauthorcontributorsfilesmainbinmandirectoriesscriptsscripts específicos de npmconfigdependenciesdevDependenciespeerDependenciesoptionalDependenciesbundledDependenciesenginesoscpulibcprivatepublishConfigflatresolutionsworkspacesboltunpkgtypesflow:mainbrowserslistmodulebrowseresnextes2015esmmodule-browsermodules.rootjsnext:mainreact-nativesideEffectssource , umd:mainsource@std/esmjspmignoreformatregistryshimmapbrowserify.transformproxyhomepagebabeleslintConfigjeststylelintsize-limitpwmetricsavanycpreferGlobalstylelessstandard Los dos campos más importantes en su package.json son name y version , sin ellos su paquete no podrá instalarse. Los campos name y version se utilizan juntos para crear una identificación única.
name{
"name" : " my-awesome-package "
} Este es el nombre de su paquete. Se utiliza en URL, como argumento en la línea de comando y como nombre de directorio dentro de node_modules .
yarn add [name] node_modules/[name]
https://registry.npmjs.org/[name]/-/[name]-[version].tgz
Normas
@scope/ para paquetes con ámbito).. ) ni un guión bajo ( _ ).Consejos
js o node en el nombre.require() .version{
"version" : " 1.0.0 "
}La versión actual de su paquete.
description{
"description" : " My short description of my awesome package "
}La descripción es sólo una cadena que ayuda a las personas a comprender el propósito del paquete. También se puede utilizar al buscar paquetes en un administrador de paquetes.
keywords{
"keywords" : [ " short " , " relevant " , " keywords " , " for " , " searching " ]
}Las palabras clave son una serie de cadenas que resultan útiles al buscar paquetes en un administrador de paquetes.
license{
"license" : " MIT " ,
"license" : " (MIT or GPL-3.0) " ,
"license" : " SEE LICENSE IN LICENSE_FILENAME.txt " ,
"license" : " UNLICENSED "
}Todos los paquetes deben especificar una licencia para que los usuarios sepan cómo se les permite usarla y las restricciones que se le imponen.
Se le recomienda utilizar una licencia de código abierto (aprobada por OSI) a menos que tenga un motivo específico para no hacerlo. Si creó su paquete como parte de su trabajo, probablemente sea mejor consultar con su empresa antes de decidirse por una licencia.
Debe ser uno de los siguientes:
SEE LICENSE IN <filename> que apunta a un <filename> en el nivel superior de su paquete si está utilizando una licencia no estándar.UNLICENSED si no desea otorgar a otros el derecho a usar un paquete privado o no publicado bajo ningún término. Varios enlaces a documentación, lugares para presentar problemas y dónde reside realmente el código de su paquete.
homepage{
"homepage" : " https://your-package.org "
}La página de inicio es la URL de la página de destino o la documentación de su paquete.
También utilizado por la aplicación Create React
bugs{
"bugs" : " https://github.com/user/repo/issues "
}La URL del rastreador de problemas de su proyecto. Esto también puede ser algo así como una dirección de correo electrónico. Proporciona a los usuarios una forma de saber dónde enviar los problemas con su paquete.
repository{
"repository" : { "type" : " git " , "url" : " https://github.com/user/repo.git " },
"repository" : " github:user/repo " ,
"repository" : " gitlab:user/repo " ,
"repository" : " bitbucket:user/repo " ,
"repository" : " gist:a1b2c3d4e5f "
}El repositorio es la ubicación donde reside el código real de su paquete.
Los mantenedores de su proyecto.
author{
"author" : { "name" : " Your Name " , "email" : " [email protected] " , "url" : " http://your-website.com " },
"author" : " Your Name <[email protected]> (http://your-website.com) "
}Información del autor del paquete. Un autor es una sola persona.
contributors{
"contributors" : [
{ "name" : " Your Friend " , "email" : " [email protected] " , "url" : " http://friends-website.com " }
{ "name" : " Other Friend " , "email" : " [email protected] " , "url" : " http://other-website.com " }
],
"contributors" : [
" Your Friend <[email protected]> (http://friends-website.com) " ,
" Other Friend <[email protected]> (http://other-website.com) "
]
}Aquellos que han contribuido a su paquete. Los contribuyentes son una variedad de personas.
Puede especificar los archivos que se incluirán en su proyecto, junto con el punto de entrada principal de su proyecto.
files{
"files" : [
" filename.js " ,
" directory/ " ,
" glob/*.{js,json} "
]
}Estos son archivos que se incluyen en su proyecto. Puede especificar archivos individuales, directorios completos o utilizar comodines para incluir archivos que cumplan con ciertos criterios.
main{
"main" : " filename.js "
}Este es el punto de entrada principal para la funcionalidad de su proyecto.
bin{
"bin" : " bin.js " ,
"bin" : {
"command-name" : " bin/command-name.js " ,
"other-command" : " bin/other-command "
}
}Archivos ejecutables incluidos con su proyecto que se instalará.
man{
"man" : " ./man/doc.1 " ,
"man" : [ " ./man/doc.1 " , " ./man/doc.2 " ]
}Si tiene páginas de manual asociadas con su proyecto, agréguelas aquí.
directories{
"directories" : {
"lib" : " path/to/lib/ " ,
"bin" : " path/to/bin/ " ,
"man" : " path/to/man/ " ,
"doc" : " path/to/doc/ " ,
"example" : " path/to/example/ "
}
}Al instalar su paquete, puede especificar ubicaciones exactas para colocar archivos binarios, páginas de manual, documentación, ejemplos, etc.
Su paquete puede incluir scripts ejecutables u otra configuración.
scripts{
"scripts" : {
"build-project" : " node build-project.js "
}
} Los scripts son una excelente manera de automatizar tareas relacionadas con su paquete, como procesos de compilación simples o herramientas de desarrollo. Usando el campo "scripts" , puede definir varios scripts para que se ejecuten como yarn run <script> . Por ejemplo, el script build-project anterior se puede invocar con yarn run build-project y ejecutará node build-project.js .
Ciertos nombres de guiones son especiales. Si está definido, Yarn llama al script preinstall antes de instalar el paquete. Por motivos de compatibilidad, los scripts denominados install , postinstall y prepublish se llamarán después de que el paquete haya terminado de instalarse.
El valor predeterminado del script start es node server.js .
"scripts": {"start": "node server.js"}. Si hay un archivo server.js en la raíz de su paquete, entonces npm establecerá de forma predeterminada el comando de inicio en el nodo server.js.
"scripts":{"preinstall": "node-gyp rebuild"}. Si hay un archivo vinculante.gyp en la raíz de su paquete, npm utilizará de forma predeterminada el comando de preinstalación para compilar usando node-gyp.-- documentos npm
scripts específicos de npm npm admite la propiedad scripts del archivo package.json , para los siguientes scripts:
prepublish : se ejecuta ANTES de que el paquete esté empaquetado y publicado, así como en la instalación local de npm sin ningún argumento. (Vea abajo)prepare : ejecute ambos ANTES de empaquetar y publicar el paquete, y en la instalación local de npm sin ningún argumento (consulte a continuación). Esto se ejecuta DESPUÉS de la publicación previa, pero ANTES de la publicación previa únicamente.prepublishOnly : se ejecuta ANTES de que se prepare y empaquete el paquete, SÓLO en npm Publish. (Vea abajo.)prepack : se ejecuta ANTES de empaquetar un tarball (en npm pack, npm Publish y al instalar dependencias de git)postpack : Ejecutar DESPUÉS de que el tarball haya sido generado y movido a su destino final.publish , postpublish : ejecutar DESPUÉS de que se publique el paquete.preinstall : ejecutar ANTES de que se instale el paqueteinstall , postinstall : ejecutar DESPUÉS de instalar el paquete.preuninstall , uninstall : ejecutar ANTES de desinstalar el paquete.postuninstall : Ejecutar DESPUÉS de desinstalar el paquete.preversion : Ejecute ANTES de actualizar la versión del paquete.version : Ejecute DESPUÉS de actualizar la versión del paquete, pero ANTES de confirmar.postversion : Ejecute DESPUÉS de actualizar la versión del paquete y DESPUÉS de confirmar.pretest , test , posttest : se ejecuta mediante el comando npm test.prestop , stop , poststop : ejecutado por el comando npm stop.prestart , start , poststart : ejecutado por el comando npm start.prerestart , restart , postrestart : ejecutado por el comando npm restart. Nota: npm restart ejecutará los scripts de parada e inicio si no se proporciona ningún script de reinicio.preshrinkwrap , shrinkwrap , postshrinkwrap : se ejecuta con el comando npm Shrinkwrap.Fuente: documentos npm.
config{
"config" : {
"port" : " 8080 "
}
}Opciones de configuración o parámetros utilizados en sus scripts.
Es muy probable que su paquete dependa de otros paquetes. Puede especificar esas dependencias en su archivo package.json .
dependencies{
"dependencies" : {
"package-1" : " ^3.1.4 "
}
}Estas son dependencias necesarias tanto en el desarrollo como en la producción de su paquete.
Puede especificar una versión exacta, una versión mínima (por ejemplo,
>=) o un rango de versiones (por ejemplo,>= ... <).
devDependencies{
"devDependencies" : {
"package-2" : " ^0.4.2 "
}
}Estos son paquetes que solo son necesarios al desarrollar su paquete pero que no se instalarán en producción.
peerDependencies{
"peerDependencies" : {
"package-3" : " ^2.7.18 "
}
}Las dependencias entre pares le permiten indicar la compatibilidad de su paquete con versiones de otros paquetes.
optionalDependencies{
"optionalDependencies" : {
"package-5" : " ^1.6.1 "
}
}Se pueden utilizar dependencias opcionales con su paquete, pero no son obligatorias. Si no se encuentra el paquete opcional, la instalación continúa.
bundledDependencies{
"bundledDependencies" : [
" package-4 "
]
}Las dependencias empaquetadas son una serie de nombres de paquetes que se agruparán al publicar su paquete.
Puede proporcionar información a nivel de sistema asociada con su paquete, como la compatibilidad del sistema operativo, etc.
engines{
"engines" : {
"node" : " >=4.4.7 <7.0.0 " ,
"zlib" : " ^1.2.8 " ,
"yarn" : " ^0.14.0 "
}
} Los motores especifican versiones de clientes que deben usarse con su paquete. Esto verifica process.versions y la versión actual de hilo.
os{
"os" : [ " darwin " , " linux " ],
"os" : [ " !win32 " ]
} Esto especifica la compatibilidad del sistema operativo para su paquete. Se compara con process.platform .
cpu{
"cpu" : [ " x64 " , " ia32 " ],
"cpu" : [ " !arm " , " !mips " ]
} Utilice esto para especificar que su paquete solo se ejecutará en determinadas arquitecturas de CPU. Esto se compara con process.arch .
libc{
"libc" : [ " glibc " ],
"libc" : [ " musl " ]
} Utilice esto para especificar que su paquete solo se ejecute en un tipo específico de libc. Esto se compara con el resultado de detect-libc .
private{
"private" : true
} Si no desea que su paquete se publique en un administrador de paquetes, configúrelo en true .
publishConfig{
"publishConfig" : {
...
}
}Estos valores de configuración se utilizarán al publicar su paquete. Puedes etiquetar tu paquete, por ejemplo.
flat{
"flat" : true
} Si su paquete solo permite una versión de una dependencia determinada y desea aplicar el mismo comportamiento que yarn install --flat en la línea de comando, configúrelo en true .
Tenga en cuenta que si su package.json contiene "flat": true y otros paquetes dependen del suyo (por ejemplo, está creando una biblioteca en lugar de una aplicación), esos otros paquetes también necesitarán "flat": true en su package.json o ser instalado con yarn install --flat en la línea de comando.
resolutions{
"resolutions" : {
"transitive-package-1" : " 0.0.29 " ,
"transitive-package-2" : " file:./local-forks/transitive-package-2 " ,
"dependencies-package-1/transitive-package-3" : " ^2.1.1 "
}
}Le permite anular una versión de una dependencia anidada particular. Consulte el RFC de resoluciones de versiones selectivas para obtener las especificaciones completas.
Tenga en cuenta que la instalación de dependencias mediante [ yarn install --flat ] agregará automáticamente un bloque resolutions a su archivo package.json .
workspaces Si --use-workspaces es verdadero, packages serán anulados por el valor de package.json/workspaces .
Fuente: --use-workspaces.
boltVer Configuración
{
"bolt" : {
"workspaces" : [
" utils/* " ,
" apps/* "
]
}
}unpkg Si omite la ruta del archivo (es decir, utiliza una URL "simple"), unpkg entregará el archivo especificado por el campo unpkg en package.json , o recurrirá a main (fuente).
types Si su paquete tiene un archivo .js principal, deberá indicar también el archivo de declaración principal en su archivo package.json . Establezca la propiedad types para que apunte a su archivo de declaración incluido. Por ejemplo:
{
"main" : " ./lib/main.js " ,
"types" : " ./lib/main.d.ts "
} Tenga en cuenta que el campo typings es sinónimo de types y también podría usarse.
También tenga en cuenta que si su archivo de declaración principal se llama index.d.ts y se encuentra en la raíz del paquete (al lado de index.js ), no necesita marcar la propiedad types , aunque es recomendable hacerlo.
Fuente: documentación de TypeScript
Nota: en Flow utilizan un enfoque diferente
flow:mainNo soportado oficialmente. La propuesta está aquí.
browserslist? Biblioteca para compartir navegadores de destino entre diferentes herramientas de front-end. Se utiliza en:
package.json o archivos browserslist compatibles con 2.0) Todas las herramientas que dependen de Browserslist encontrarán su configuración automáticamente cuando agregue lo siguiente a package.json :
{
"browserslist" : [
" > 1% " ,
" last 2 versions "
]
}Fuente: lista de navegadores.
Ver también: Crear compatibilidad con la aplicación React.
Consulte "Configuración de paquetes npm multiplataforma" para obtener una introducción.
module pkg.module apuntará a un módulo que tenga la sintaxis del módulo ES2015 pero, por lo demás, solo características de sintaxis que admitan los entornos de destino. La descripción completa está aquí.
Soportado por: rollup, paquete web
browser El autor del módulo proporciona el campo browser como una sugerencia para los paquetes de JavaScript o las herramientas de componentes al empaquetar módulos para uso del lado del cliente. La propuesta está aquí.
Soportado por: rollup, webpack, browserify
Soporte solicitado: babel-plugin-module-resolver
esnextLa propuesta completa está aquí. Breve explicación:
esnext : código fuente que utiliza funciones de la etapa 4 (o anteriores), no transpilado, en módulos ES.main : apunta a un módulo CommonJS (o módulo UMD) con JavaScript tan moderno como el que Node.js puede manejar actualmente.module deberían poder manejarse a través de esnext .browser se puede manejar a través de una versión extendida de esnext {
"main" : " main.js " ,
"esnext" : {
"main" : " main-esnext.js " ,
"browser" : " browser-specific-main-esnext.js "
}
}Ver también: Entrega de código fuente no transpilado a través de npm
es2015Código ES6 no transpilado. Fuente: Formato de paquete angular (APF) v5.0
esmLa propuesta está aquí: propuesta ajustada: módulo ES "esm": bandera true package.json
Ver también:
module-browserVer este número
También conocido como moduleBrowser , jsnext:browser .
modules.rootMencionado en En defensa de .js.
También hay modules.resolver .
jsnext:mainDESPRECADO
jsnext:main ha sido reemplazado por pkg.module , que indica la ubicación de un archivo con declaraciones de importación/exportación. La propuesta original está aquí.
Respaldado por: resumen.
react-native Funciona de manera similar al browser , pero para módulos específicos nativos de reacción. Fuente.
sideEffectsIndica que los módulos del paquete no tienen efectos secundarios (en la evaluación) y solo exponen exportaciones. Esto permite que herramientas como webpack optimicen las reexportaciones.
Ver también: ejemplo sideEffects , propuesta para marcar funciones como puras, eslint-plugin-tree-shaking.
source , umd:mainConsulte Especificación de compilaciones en package.json.
sourceConsulte paquete-paquete/paquete#1652.
@std/esm Los desarrolladores tienen opiniones firmes sobre casi todo. Para adaptarse, @std/esm permite desbloquear funciones adicionales con el campo "@std/esm" o "@std":{"esm":{}} en su package.json .
Fuente: @std/esm Desbloqueables
jspm Puede escribir todas las propiedades del paquete en la base de package.json, o si no desea cambiar las propiedades existentes que le gustaría usar específicamente para npm , puede escribir su configuración específica de jspm dentro de la propiedad jspm de package.json y jspm utilizarán estas opciones sobre las opciones de configuración del nivel raíz.
Por ejemplo:
{
"name" : " my-package " ,
"jspm" : {
"main" : " jspm-main "
}
}Ver especificación completa.
ignoreSi hay ciertos archivos o carpetas específicos que se deben ignorar, se pueden enumerar en una matriz.
format Las opciones son esm , amd , cjs y global .
Al cargar módulos desde
npm, el formato del módulo se trata comocjsde forma predeterminada y no se ejecuta ninguna detección automática. Para cargar módulos de otro formato, deberá anular esta propiedad manualmente.
El formato del módulo
esm(módulo ECMAScript) actualmente no se utiliza en package.json.
registryjspm entiende las dependencias en el contexto de un registro.
Al cargar paquetes desde npm, jspm establecerá el registro predeterminado en npm y tratará las dependencias en consecuencia.
Al cargar paquetes desde GitHub, la propiedad de dependencias se ignora sin que esté presente una propiedad de registro, ya que jspm no tiene forma de saber qué significan las dependencias para los repositorios de GitHub existentes.
Establecer la propiedad del registro también determina cómo jspm interpreta el paquete. Por ejemplo, un paquete de GitHub con registry: "npm" , además de obtener sus dependencias de npm, se interpretará como CommonJS y admitirá funciones como el directorio y los requisitos JSON, exactamente como si se hubiera instalado desde el punto final de npm para empezar.
Un paquete en GitHub con su propiedad de registro establecida en registry: "jspm" tendrá sus dependencias tratadas como dependencias de estilo jspm.
shim Los paquetes escritos como globales necesitan una configuración de corrección para funcionar correctamente en un entorno modular. Para calzar un archivo some/global.js dentro del paquete, podemos escribir:
{
"shim" : {
"some/global" : {
"deps" : [ " jquery " ],
"exports" : " globalExportName "
}
}
} Tanto deps como exports son opcionales.
El cargador SystemJS detecta automáticamente exports como cualquier global escrito por el script. En la mayoría de los casos esta detección funcionará correctamente.
La forma de acceso directo de "some/global": ["jquery"] también se admite si no hay exports .
mapLa configuración del mapa reescribirá los requisitos internos para apuntar a diferentes módulos locales o externos.
Considere un paquete que incluye su propia dependencia, dep ubicado third_party/dep . Podría tener una declaración requerida internamente algo como:
require ( 'dep' ) ;Para utilizar la versión local, podemos escribir:
{
"map" : {
"dep" : " ./third_party/dep "
}
}También puede resultar útil hacer referencia a un paquete por su propio nombre dentro de los submódulos:
{
"map" : {
"thispackage" : " . "
}
} Luego podemos hacer que los requisitos internos para import 'thispackage/module' se resuelvan correctamente.
La configuración del mapa también puede hacer referencia a submódulos de dependencia.
También podemos excluir módulos por completo mapeándolos al módulo vacío:
{
"map" : {
"jquery" : " @empty "
}
}El valor devuelto será entonces un objeto Módulo sin exportaciones.
browserify.transformLa documentación está aquí.
proxyLas personas suelen servir la aplicación React front-end desde el mismo host y puerto que su implementación backend.
Fuente: Solicitudes de API de proxy en desarrollo
homepageFuente: Construyendo para caminos relativos
babelVea este problema.
eslintConfigjest{
"jest" : {
"verbose" : true
}
}
Fuente: documentos de broma
stylelintVer: Nuevo cargador de configuración
size-limit Si está utilizando esta biblioteca, puede definir su configuración en package.json :
{
"size-limit" : [
{
"limit" : " 9 KB " ,
"path" : " index.js "
}
]
}Fuente: límite de tamaño
pwmetrics Puedes especificar opciones en package.json :
{
"pwmetrics" : {
"url" : " http://example.com/ " ,
"expectations" : {
"ttfcp" : {
"warn" : " >=1500 " ,
"error" : " >=2000 "
}
}
}
}Todas las opciones disponibles están aquí.
Fuente: pwmetrics
avaEjemplo:
"ava" : {
"require" : [ " @std/esm " ]
}Fuente: ava
nycEjemplo:
"nyc" : {
"extension" : [ " .js " , " .mjs " ],
"require" : [ " @std/esm " ]
}Fuente: Nueva York
preferGlobalDESPRECADO
Esta opción solía activar una advertencia de npm, pero ya no lo hará. Está ahí únicamente con fines informativos. Ahora se recomienda instalar los archivos binarios como devDependencies locales siempre que sea posible.
style El atributo style en package.json es útil para importar paquetes CSS. La propuesta está aquí.
Compatible con: parcelar, npm-less, rework-npm, npm-css.
Ver también: istf-spec.
less Lo mismo que style pero por menos.
Soportado por: npm-less.
Los siguientes campos están reservados para futuras expansiones: build , default , email , files external , imports , maintainer , paths , platform , require , summary , test , using , downloads , uid .
Los siguientes campos están reservados para que los registros de paquetes los utilicen a su discreción: id , type .
Todas las propiedades que comienzan con _ o $ también están reservadas para que los registros de paquetes las utilicen a su discreción.
Fuente: wiki de CommonJS
standard Standard JS es una guía de estilo, linter y formateador de JavaScript. Puede agregar algunas propiedades a package.json, como parser , ignore , globals , plugins .
Ejemplo:
"standard" : {
"parser" : " babel-eslint " ,
"ignore" : [
" **/out/ " ,
" /lib/select2/ " ,
" /lib/ckeditor/ " ,
" tmp.js "
]
}Ver también: JS estándar
