Al crear el package.json, ya bien de forma manual o automáticamente, vamos a encontrar dentro de el un gran objeto con múltiples keys y valores. Para no dejar espacio a dudas, este es un listado de las keys que podemos agregar, que significa cada una, y algunas recomendaciones a tener en cuenta:
name
Uno de los dos campos obligatorios (junto a version). Es un string que representa el nombre del proyecto actual y forma un identificador único entre este campo y version en caso de que sea publicado al registro de npm.
version
Como el nombre lo indica, es un string con la versión actual del proyecto. Los paquetes/proyectos/librerías en Node y JS siguen las convenciones definidas en Semantic Versioning (o semver para los más amigos), la cual define la forma de versionamiento:
MAJOR.MINOR.PATCH
description
Un string que describa lo que hace este proyecto. En caso de que decidamos publicar en el registro de npm, este texto ayudará a la gente a encontrarlo mediante la búsqueda de npm.
keywords
Igual a description, pero en vez de texto, es un array de strings que incluye términos que puedan ser utilizados para una eventual búsqueda.
homepage
Es un string con la URL del proyecto.
license
Es un string que especifica que tipo de licencia definimos para el uso de este proyecto, ya sea de forma personal, comercial, abierta y/o privada.
author
Puede ser un string o un objeto con la información del creador del proyecto.
main
Un string que define la ruta del archivo principal o punto de entrada de tu proyecto. Este es el archivo que una persona recibirá si importa tu proyecto al suyo.
scripts
Es un objeto que indica comandos que podemos correr dentro de nuestro proyecto, asociándolos a una palabra clave para que npm (o yarn) los reconozca cuando queramos ejecutarlos.
dependencies
Un objeto que guarda los nombres y versiones de cada dependencia que hemos instalado dentro del proyecto. De esta forma, cada vez que alguien obtenga una copia de este proyecto, y corra el comando npm install, se instalarán todas las dependencias que aquí estén definidas y por ende, no habrán problemas de compatibilidad al correr el proyecto.
devDependencies
Mismo formato que las dependencias, pero acá podemos incluir todas aquellas librerías que no son necesarias para que este proyecto corra en producción, o cuando sea requerido e instalado dentro de otro. Con esto le ahorramos a quien importe este proyecto de tener dependencias instaladas que pueden no ser necesarias para que esto funcione (como por ejemplo herramientas de tests).
y mas…
excelente Gracias