หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด

แพ็คเกจ.json

ข้อควรระวัง อย่าใช้ package.json สำหรับชื่อโฟลเดอร์ หากคุณต้องการโคลนโปรเจ็กต์นี้ไปยังเครื่องของคุณ - มันจะขาด yarn ( An unexpected error occurred: "EISDIR: illegal operation on a directory, read". )

เอกสารต้นฉบับนี้คัดลอกมาจาก Yarnpkg

ดูเพิ่มเติมที่เอกสารประกอบ npm, std-pkg, clean-publish, package-json-validator, cosmiconfig, rc (เป็นแนวทางของฝ่ายตรงข้ามกับ cosmiconfig)

  • สิ่งจำเป็น
    • name
    • version
  • ข้อมูล
    • description
    • keywords
    • license
  • ลิงค์
    • homepage
    • bugs
    • repository
  • ผู้ดูแล
    • author
    • contributors
  • ไฟล์
    • files
    • main
    • bin
    • man
    • directories
  • งาน
    • scripts
    • scripts เฉพาะ NPM
    • config
  • การพึ่งพาอาศัยกัน
    • dependencies
    • devDependencies
    • peerDependencies
    • optionalDependencies
    • bundledDependencies
  • ระบบ
    • engines
    • os
    • cpu
    • libc
  • การเผยแพร่
    • private
    • publishConfig
  • เส้นด้าย
    • flat
    • resolutions
  • เลิร์นา + เส้นด้าย
    • workspaces
  • สายฟ้า
    • bolt
  • แกะกล่องออก
    • unpkg
  • TypeScript
    • types
  • ไหล
    • flow:main
  • รายการเบราว์เซอร์
    • browserslist
  • เครื่องมัดแพ็คเกจ
    • module
    • browser
    • esnext
    • es2015
    • esm
    • module-browser
    • modules.root
    • jsnext:main
  • รถไฟใต้ดิน
    • react-native
  • เว็บแพ็ก
    • sideEffects
  • ไมโครมัด
    • source , umd:main
  • พัสดุ
    • source
  • @std/esm
    • @std/esm
  • jspm
    • jspm
    • ignore
    • format
    • registry
    • shim
    • map
  • เบราว์เซอร์
    • browserify.transform
  • สร้างแอป React
    • proxy
    • homepage
  • บาเบล
    • babel
  • เอสลินท์
    • eslintConfig
  • ล้อเล่น
    • jest
  • สไตล์ลินท์
    • stylelint
  • ขีดจำกัดขนาด
    • size-limit
  • พีเอ็มเมตริก
    • pwmetrics
  • เอวา
    • ava
  • นิวยอร์ก
    • nyc
  • อื่น
    • preferGlobal
    • style
    • less
  • แพ็คเกจ CommonJS
    • คุณสมบัติที่สงวนไว้
  • เจเอสมาตรฐาน
    • standard

สิ่งจำเป็น

ช่องที่สำคัญที่สุดสองช่องใน package.json ของคุณคือ name และ version หากไม่มีช่องเหล่านี้ แพ็คเกจของคุณจะไม่สามารถติดตั้งได้ ช่อง name และ version ใช้ร่วมกันเพื่อสร้างรหัสเฉพาะ

name

{
  "name" : " my-awesome-package "
}

นี่คือชื่อแพ็คเกจของคุณ มันถูกใช้ใน URL เป็นอาร์กิวเมนต์บนบรรทัดคำสั่ง และเป็นชื่อไดเร็กทอรีภายใน node_modules 

yarn add [name]
 node_modules/[name]

 https://registry.npmjs.org/[name]/-/[name]-[version].tgz

กฎ

  • ต้องน้อยกว่าหรือเท่ากับ 214 อักขระ (รวม @scope/ สำหรับแพ็คเกจที่กำหนดขอบเขต)
  • ต้องไม่ขึ้นต้นด้วยจุด ( . ) หรือขีดล่าง ( _ )
  • ต้องไม่มีอักษรตัวพิมพ์ใหญ่ในชื่อ
  • ต้องใช้อักขระที่ปลอดภัยต่อ URL เท่านั้น

เคล็ดลับ

  • อย่าใช้ชื่อเดียวกันกับโมดูล Node.js หลัก
  • อย่าใส่ js หรือ node ในชื่อ
  • ใช้ชื่อให้สั้นและสื่อความหมาย คุณต้องการให้ผู้คนเข้าใจว่ามันมาจากชื่ออะไร แต่จะใช้ในการเรียก require() ด้วย
  • ตรวจสอบให้แน่ใจว่าไม่มีบางสิ่งในรีจิสทรีที่มีชื่อเดียวกัน

version

{
  "version" : " 1.0.0 "
}

เวอร์ชันปัจจุบันของแพ็คเกจของคุณ

ข้อมูล

description

{
  "description" : " My short description of my awesome package "
}

คำอธิบายเป็นเพียงสตริงที่ช่วยให้ผู้คนเข้าใจวัตถุประสงค์ของแพ็คเกจ สามารถใช้เมื่อค้นหาแพ็คเกจในตัวจัดการแพ็คเกจได้เช่นกัน

keywords

{
  "keywords" : [ " short " , " relevant " , " keywords " , " for " , " searching " ]
}

คำสำคัญคืออาร์เรย์ของสตริงที่มีประโยชน์เมื่อค้นหาแพ็คเกจในตัวจัดการแพ็คเกจ

license

{
  "license" : " MIT " ,
  "license" : " (MIT or GPL-3.0) " ,
  "license" : " SEE LICENSE IN LICENSE_FILENAME.txt " ,
  "license" : " UNLICENSED "
}

แพ็คเกจทั้งหมดควรระบุใบอนุญาตเพื่อให้ผู้ใช้ทราบว่าพวกเขาได้รับอนุญาตให้ใช้งานอย่างไร และข้อจำกัดใด ๆ ที่คุณกำหนดไว้

เราขอแนะนำให้คุณใช้ใบอนุญาตโอเพ่นซอร์ส (ได้รับการอนุมัติจาก OSI) เว้นแต่คุณจะมีเหตุผลเฉพาะเจาะจงที่จะไม่ทำเช่นนั้น หากคุณสร้างแพ็คเกจโดยเป็นส่วนหนึ่งของงาน คุณควรตรวจสอบกับบริษัทของคุณก่อนที่จะตัดสินใจเกี่ยวกับใบอนุญาต

จะต้องเป็นหนึ่งในสิ่งต่อไปนี้:

  • ตัวระบุใบอนุญาต SPDX ที่ถูกต้อง หากคุณใช้ใบอนุญาตมาตรฐาน
  • นิพจน์ไวยากรณ์นิพจน์สิทธิ์การใช้งาน SPDX ที่ถูกต้อง 2.0 หากคุณใช้สิทธิ์การใช้งานมาตรฐานหลายรายการ
  • SEE LICENSE IN <filename> ที่ชี้ไปที่ <filename> ในระดับบนสุดของแพ็คเกจของคุณ หากคุณใช้ใบอนุญาตที่ไม่ได้มาตรฐาน
  • สตริง UNLICENSED หากคุณไม่ต้องการให้สิทธิ์ผู้อื่นในการใช้แพ็คเกจส่วนตัวหรือที่ไม่ได้เผยแพร่ภายใต้ข้อกำหนดใด ๆ

ลิงค์

ลิงก์ต่างๆ ไปยังเอกสาร สถานที่ยื่นปัญหา และที่อยู่ของรหัสแพ็คเกจของคุณ

homepage

{
  "homepage" : " https://your-package.org "
}

หน้าแรกคือ URL ไปยังหน้า Landing Page หรือเอกสารประกอบสำหรับพัสดุของคุณ

ใช้โดย Create React App ด้วย

bugs

{
  "bugs" : " https://github.com/user/repo/issues "
}

URL ไปยังเครื่องมือติดตามปัญหาของโครงการของคุณ นี่อาจเป็นที่อยู่อีเมลได้เช่นกัน มันให้วิธีการแก่ผู้ใช้ในการค้นหาว่าจะส่งปัญหาเกี่ยวกับแพ็คเกจของคุณได้ที่ไหน

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

พื้นที่เก็บข้อมูลคือตำแหน่งที่มีรหัสจริงสำหรับแพ็คเกจของคุณ

ผู้ดูแล

ผู้ดูแลโครงการของคุณ

author

{
  "author" : { "name" : " Your Name " , "email" : " [email protected] " , "url" : " http://your-website.com " },
  "author" : " Your Name <[email protected]> (http://your-website.com) "
}

ข้อมูลผู้เขียนแพ็คเกจ ผู้เขียนก็เป็นคนคนหนึ่ง

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) "
  ]
}

ผู้ที่มีส่วนร่วมในแพ็คเกจของคุณ ผู้ร่วมให้ข้อมูลเป็นกลุ่มคน

ไฟล์

คุณสามารถระบุไฟล์ที่จะรวมไว้ในโปรเจ็กต์ของคุณ พร้อมด้วยจุดเริ่มต้นหลักสำหรับโปรเจ็กต์ของคุณ

files

{
  "files" : [
    " filename.js " ,
    " directory/ " ,
    " glob/*.{js,json} "
  ]
}

ไฟล์เหล่านี้คือไฟล์ที่รวมอยู่ในโปรเจ็กต์ของคุณ คุณสามารถระบุไฟล์เดียว ทั้งไดเร็กทอรี หรือใช้ไวด์การ์ดเพื่อรวมไฟล์ที่ตรงตามเกณฑ์ที่กำหนดได้

main

{
  "main" : " filename.js "
}

นี่คือจุดเริ่มต้นหลักสำหรับฟังก์ชันการทำงานสำหรับโครงการของคุณ

bin

{
  "bin" : " bin.js " ,
  "bin" : {
    "command-name" : " bin/command-name.js " ,
    "other-command" : " bin/other-command "
  }
}

ไฟล์ปฏิบัติการที่มาพร้อมกับโปรเจ็กต์ของคุณที่จะถูกติดตั้ง

man

{
  "man" : " ./man/doc.1 " ,
  "man" : [ " ./man/doc.1 " , " ./man/doc.2 " ]
}

หากคุณมีหน้าคู่มือที่เกี่ยวข้องกับโครงการของคุณ ให้เพิ่มได้ที่นี่

directories

{
  "directories" : {
    "lib" : " path/to/lib/ " ,
    "bin" : " path/to/bin/ " ,
    "man" : " path/to/man/ " ,
    "doc" : " path/to/doc/ " ,
    "example" : " path/to/example/ "
  }
}

เมื่อติดตั้งแพ็คเกจของคุณ คุณสามารถระบุตำแหน่งที่แน่นอนเพื่อใส่ไฟล์ไบนารี หน้าคู่มือ เอกสาร ตัวอย่าง ฯลฯ

งาน

แพ็คเกจของคุณสามารถรวมสคริปต์ที่รันได้หรือการกำหนดค่าอื่น ๆ

scripts

{
  "scripts" : {
    "build-project" : " node build-project.js "
  }
}

สคริปต์เป็นวิธีที่ยอดเยี่ยมในการทำงานอัตโนมัติที่เกี่ยวข้องกับแพ็คเกจของคุณ เช่น กระบวนการสร้างแบบง่ายๆ หรือเครื่องมือการพัฒนา การใช้ฟิลด์ "scripts" คุณสามารถกำหนดสคริปต์ต่างๆ ที่จะรันเป็น yarn run <script> ได้ ตัวอย่างเช่น สคริปต์ build-project ด้านบนสามารถเรียกใช้ด้วย yarn run build-project และจะรัน node build-project.js

ชื่อสคริปต์บางตัวเป็นชื่อพิเศษ หากกำหนดไว้ สคริปต์ preinstall จะถูกเรียกโดยเส้นด้ายก่อนที่แพ็คเกจของคุณจะถูกติดตั้ง เพื่อเหตุผลด้านความเข้ากันได้ สคริปต์ที่เรียกว่า install , postinstall และ prepublish จะถูกเรียกทั้งหมดหลังจากแพ็คเกจของคุณติดตั้งเสร็จแล้ว

ค่าสคริปต์ start มีค่าเริ่มต้นเป็น node server.js

"scripts": {"start": "node server.js"} หากมีไฟล์ server.js อยู่ในรูทของแพ็คเกจของคุณ npm จะใช้คำสั่งเริ่มต้นเป็น node server.js

"scripts":{"preinstall": "node-gyp rebuild"} หากมีไฟล์binding.gypอยู่ในรูทของแพ็คเกจของคุณ npm จะใช้คำสั่งติดตั้งล่วงหน้าเป็นค่าเริ่มต้นเพื่อคอมไพล์โดยใช้ node-gyp

-- เอกสาร npm

scripts เฉพาะ NPM

npm รองรับคุณสมบัติ scripts ของไฟล์ package.json สำหรับสคริปต์ต่อไปนี้:

  • prepublish : รันก่อนที่แพ็คเกจจะถูกแพ็กและเผยแพร่ รวมถึงการติดตั้ง npm ในเครื่องโดยไม่มีข้อโต้แย้งใด ๆ (ดูด้านล่าง)
  • prepare : รันทั้งคู่ก่อนที่แพ็คเกจจะถูกแพ็กและเผยแพร่ และในการติดตั้ง npm ในเครื่องโดยไม่มีข้อโต้แย้งใด ๆ (ดูด้านล่าง) สิ่งนี้จะดำเนินการหลังจากเผยแพร่ล่วงหน้า แต่ก่อนที่จะเผยแพร่ล่วงหน้าเท่านั้น
  • prepublishOnly : รันก่อนที่แพ็คเกจจะถูกจัดเตรียมและบรรจุ เฉพาะในการเผยแพร่ npm เท่านั้น (ดูด้านล่าง)
  • prepack : รันก่อนที่จะแพ็ก tarball (บนแพ็ก npm, การเผยแพร่ npm และเมื่อติดตั้งการพึ่งพาคอมไพล์)
  • postpack : Run AFTER tarball ถูกสร้างขึ้นและย้ายไปยังปลายทางสุดท้าย
  • publish , postpublish : เรียกใช้หลังจากเผยแพร่แพ็คเกจแล้ว
  • preinstall : เรียกใช้ก่อนที่จะติดตั้งแพ็คเกจ
  • install , postinstall : เรียกใช้หลังจากติดตั้งแพ็คเกจแล้ว
  • preuninstall , uninstall : เรียกใช้ก่อนที่จะถอนการติดตั้งแพ็คเกจ
  • postuninstall : เรียกใช้หลังจากถอนการติดตั้งแพ็คเกจแล้ว
  • preversion : เรียกใช้ก่อนชนเวอร์ชันแพ็คเกจ
  • version : Run AFTER กระแทกเวอร์ชันแพ็คเกจ แต่ก่อนที่จะคอมมิต
  • postversion : Run AFTER ชนรุ่นแพ็คเกจและ AFTER commit
  • pretest , test , posttest : รันโดยคำสั่ง npm test
  • prestop , stop , poststop : รันโดยคำสั่ง npm stop
  • prestart , start , poststart : รันโดยคำสั่ง npm start
  • prerestart , restart , postrestart : รันโดยคำสั่ง npm restart หมายเหตุ: การรีสตาร์ท npm จะเรียกใช้สคริปต์หยุดและเริ่ม หากไม่มีสคริปต์การรีสตาร์ทให้มา
  • preshrinkwrap , shrinkwrap , postshrinkwrap : รันโดยคำสั่ง npm Shrinkwrap

ที่มา: เอกสาร npm

config

{
  "config" : {
    "port" : " 8080 "
  }
}

ตัวเลือกการกำหนดค่าหรือพารามิเตอร์ที่ใช้ในสคริปต์ของคุณ

การพึ่งพาอาศัยกัน

แพ็คเกจของคุณมักจะขึ้นอยู่กับแพ็คเกจอื่น คุณสามารถระบุการขึ้นต่อกันเหล่านั้นได้ในไฟล์ package.json ของคุณ

dependencies

{
  "dependencies" : {
    "package-1" : " ^3.1.4 "
  }
}

สิ่งเหล่านี้เป็นการพึ่งพาที่จำเป็นทั้งในการพัฒนาและการใช้งานจริงสำหรับแพ็คเกจของคุณ

คุณสามารถระบุเวอร์ชันที่แน่นอน เวอร์ชันขั้นต่ำ (เช่น >= ) หรือช่วงเวอร์ชัน (เช่น >= ... < )

devDependencies

{
  "devDependencies" : {
    "package-2" : " ^0.4.2 "
  }
}

แพ็คเกจเหล่านี้เป็นแพ็คเกจที่จำเป็นต่อการพัฒนาแพ็คเกจของคุณเท่านั้น แต่จะไม่ได้รับการติดตั้งในการใช้งานจริง

peerDependencies

{
  "peerDependencies" : {
    "package-3" : " ^2.7.18 "
  }
}

การพึ่งพาเพียร์ทำให้คุณสามารถระบุความเข้ากันได้ของแพ็คเกจของคุณกับเวอร์ชันของแพ็คเกจอื่น ๆ

optionalDependencies

{
  "optionalDependencies" : {
    "package-5" : " ^1.6.1 "
  }
}

การพึ่งพาเพิ่มเติมสามารถใช้กับแพ็คเกจของคุณได้ แต่ไม่จำเป็น หากไม่พบแพ็กเกจเสริม การติดตั้งจะดำเนินต่อไป

bundledDependencies

{
  "bundledDependencies" : [
    " package-4 "
  ]
}

การขึ้นต่อกันแบบบันเดิลคืออาร์เรย์ของชื่อแพ็คเกจที่จะรวมเข้าด้วยกันเมื่อเผยแพร่แพ็คเกจของคุณ

ระบบ

คุณสามารถให้ข้อมูลระดับระบบที่เกี่ยวข้องกับแพ็คเกจของคุณ เช่น ความเข้ากันได้ของระบบปฏิบัติการ เป็นต้น

engines

{
  "engines" : {
    "node" : " >=4.4.7 <7.0.0 " ,
    "zlib" : " ^1.2.8 " ,
    "yarn" : " ^0.14.0 "
  }
}

เอ็นจิ้นระบุเวอร์ชันของไคลเอนต์ที่ต้องใช้กับแพ็คเกจของคุณ สิ่งนี้จะตรวจสอบกับ process.versions รวมถึงเวอร์ชันปัจจุบันของเส้นด้าย

os

{
  "os" : [ " darwin " , " linux " ],
  "os" : [ " !win32 " ]
}

นี่เป็นการระบุความเข้ากันได้ของระบบปฏิบัติการสำหรับแพ็คเกจของคุณ มันตรวจสอบกับ process.platform

cpu

{
  "cpu" : [ " x64 " , " ia32 " ],
  "cpu" : [ " !arm " , " !mips " ]
}

ใช้สิ่งนี้เพื่อระบุว่าแพ็คเกจของคุณจะทำงานบนสถาปัตยกรรม CPU บางตัวเท่านั้น สิ่งนี้จะตรวจสอบกับ process.arch

libc

{
  "libc" : [ " glibc " ],
  "libc" : [ " musl " ]
}

ใช้สิ่งนี้เพื่อระบุแพ็คเกจของคุณที่ทำงานบน libc รสชาติเฉพาะเท่านั้น สิ่งนี้จะตรวจสอบกับผลลัพธ์จาก detect-libc

  • การสนับสนุน pnpm
  • การสนับสนุนเส้นด้าย
  • รองรับ npm จะแจ้งภายหลัง

การเผยแพร่

private

{
  "private" : true
}

หากคุณไม่ต้องการเผยแพร่แพ็คเกจของคุณในตัวจัดการแพ็คเกจ ให้ตั้งค่านี้เป็น true

publishConfig

{
  "publishConfig" : {
    ...
  }
}

ค่าการกำหนดค่าเหล่านี้จะถูกนำมาใช้เมื่อเผยแพร่แพ็คเกจของคุณ คุณสามารถแท็กแพ็คเกจของคุณได้เป็นต้น

เส้นด้าย

flat

{
  "flat" : true
}

หากแพ็คเกจของคุณอนุญาตการขึ้นต่อกันที่กำหนดเพียงเวอร์ชันเดียว และคุณต้องการบังคับใช้ลักษณะการทำงานเดียวกันกับ yarn install --flat บนบรรทัดคำสั่ง ให้ตั้งค่านี้เป็น true

โปรดทราบว่าหาก package.json ของคุณมี "flat": true และแพ็คเกจอื่น ๆ ขึ้นอยู่กับคุณ (เช่น คุณกำลังสร้างไลบรารี่แทนที่จะเป็นแอปพลิเคชัน) แพ็คเกจอื่น ๆ เหล่านั้นจะต้องมี "flat": true ใน package.json หรือ ติดตั้งด้วย yarn install --flat บนบรรทัดคำสั่ง

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

ช่วยให้คุณสามารถแทนที่เวอร์ชันของการขึ้นต่อกันที่ซ้อนกันเฉพาะได้ ดู Selective Versions Resolutions RFC สำหรับข้อมูลจำเพาะทั้งหมด

โปรดทราบว่าการติดตั้งการพึ่งพาผ่าน [ yarn install --flat ] จะเพิ่มบล็อก resolutions ลงในไฟล์ package.json ของคุณโดยอัตโนมัติ

เลิร์นา + เส้นด้าย

workspaces

หาก --use-workspaces เป็นจริง packages จะถูกแทนที่ด้วยค่าจาก package.json/workspaces

ที่มา: --use-workspaces

สายฟ้า

bolt

ดูการกำหนดค่า 

{
  "bolt" : {
    "workspaces" : [
      " utils/* " ,
      " apps/* "
    ]
  }
}

แกะกล่องออก

unpkg

หากคุณละเว้นเส้นทางของไฟล์ (เช่น ใช้ URL "เปล่า") unpkg จะให้บริการไฟล์ที่ระบุโดยฟิลด์ unpkg ใน package.json หรือถอยกลับไปที่ main (ที่มา)

TypeScript

types

หากแพ็คเกจของคุณมีไฟล์ .js หลัก คุณจะต้องระบุไฟล์การประกาศหลักในไฟล์ package.json ของคุณด้วย ตั้งค่าคุณสมบัติ types ให้ชี้ไปที่ไฟล์ประกาศแบบรวมกลุ่มของคุณ ตัวอย่างเช่น: 

{
  "main" : " ./lib/main.js " ,
  "types" : " ./lib/main.d.ts "
}

โปรดทราบว่าฟิลด์ typings มีความหมายเหมือนกันกับ types และสามารถใช้ได้เช่นกัน

โปรดทราบว่าหากไฟล์การประกาศหลักของคุณชื่อ index.d.ts และอยู่ที่รูทของแพ็คเกจ (ถัดจาก index.js ) คุณไม่จำเป็นต้องทำเครื่องหมายคุณสมบัติ types แม้ว่าจะแนะนำให้ทำเช่นนั้นก็ตาม

ที่มา: เอกสาร TypeScript

หมายเหตุ: ใน Flow พวกเขาใช้วิธีการที่แตกต่างกัน

ไหล

flow:main

ไม่ได้รับการสนับสนุนอย่างเป็นทางการ ข้อเสนออยู่ที่นี่

รายการเบราว์เซอร์

browserslist

- ไลบรารีเพื่อแชร์เบราว์เซอร์เป้าหมายระหว่างเครื่องมือส่วนหน้าต่างๆ มันถูกใช้ใน:

  • คำนำหน้าอัตโนมัติ
  • babel-preset-env (การกำหนดค่าภายนอกใน package.json หรือไฟล์รายการ browserslist ที่รองรับใน 2.0)
  • postcss-preset-env
  • eslint-plugin-compat
  • stylelint-no-unsupported-browser-features
  • postcss-ทำให้เป็นมาตรฐาน

เครื่องมือทั้งหมดที่ใช้ Browserslist จะค้นหาการกำหนดค่าโดยอัตโนมัติเมื่อคุณเพิ่มสิ่งต่อไปนี้ใน package.json : 

{
  "browserslist" : [
    " > 1% " ,
    " last 2 versions "
  ]
}

ที่มา: browserslist.

ดูเพิ่มเติม: สร้างการสนับสนุนแอป React

เครื่องมัดแพ็คเกจ

ดู "การตั้งค่าแพ็คเกจ npm หลายแพลตฟอร์ม" สำหรับคำแนะนำ

module

pkg.module จะชี้ไปที่โมดูลที่มีไวยากรณ์ของโมดูล ES2015 ยกเว้นเฉพาะคุณลักษณะไวยากรณ์ที่สภาพแวดล้อมเป้าหมายรองรับเท่านั้น คำอธิบายแบบเต็มอยู่ที่นี่

สนับสนุนโดย: rollup, webpack

browser

ผู้เขียนโมดูลจัดทำฟิลด์ browser เพื่อเป็นคำแนะนำสำหรับบันเดิลจาวาสคริปต์หรือเครื่องมือส่วนประกอบเมื่อบรรจุโมดูลสำหรับการใช้งานฝั่งไคลเอ็นต์ ข้อเสนออยู่ที่นี่

สนับสนุนโดย: rollup, webpack, browserify

ขอการสนับสนุน: babel-plugin-module-resolver

esnext

ข้อเสนอที่เต็มอยู่ที่นี่ คำอธิบายสั้น ๆ :

  • esnext : ซอร์สโค้ดที่ใช้ฟีเจอร์ระยะที่ 4 (หรือเก่ากว่า) ไม่มีการทรานสไพล์ในโมดูล ES
  • main : ชี้ไปที่โมดูล CommonJS (หรือโมดูล UMD) ที่มี JavaScript ทันสมัยเท่าที่ Node.js สามารถจัดการได้ในปัจจุบัน
  • กรณีการใช้งาน module ส่วนใหญ่ควรจัดการได้ผ่าน esnext
  • browser สามารถจัดการผ่าน esnext เวอร์ชันขยายได้ 
{
  "main" : " main.js " ,
  "esnext" : {
    "main" : " main-esnext.js " ,
    "browser" : " browser-specific-main-esnext.js "
  }
}

ดูเพิ่มเติมที่: การส่งซอร์สโค้ดที่ยังไม่ได้แปลผ่านทาง npm

es2015

รหัส ES6 ที่ไม่ได้แปล ที่มา: Angular Package Format (APF) v5.0

esm

ข้อเสนออยู่ที่นี่: ข้อเสนอที่ปรับปรุงแล้ว: โมดูล ES "esm": การตั้งค่าสถานะ package.json ที่แท้จริง

ดูเพิ่มเติมที่:

  • ตัวระบุโมดูล: มีอะไรใหม่ในโมดูล ES
  • การแก้ไขการแลกเปลี่ยนส่วนขยาย mjs
  • ยืนยันอีกครั้ง

module-browser

ดูปัญหานี้

เรียกอีกอย่างว่า moduleBrowser , jsnext:browser

modules.root

กล่าวถึงใน In Defense of .js

นอกจากนี้ยังมี modules.resolver

jsnext:main

เลิกใช้แล้ว

jsnext:main ถูกแทนที่ด้วย pkg.module ซึ่งระบุตำแหน่งของไฟล์ที่มีการประกาศการนำเข้า/ส่งออก ข้อเสนอเดิมอยู่ที่นี่

สนับสนุนโดย: โรลอัพ.

รถไฟใต้ดิน

react-native

ทำงานคล้ายกับ browser แต่สำหรับโมดูลเฉพาะแบบโต้ตอบ แหล่งที่มา.

เว็บแพ็ก

sideEffects

บ่งชี้ว่าโมดูลของแพ็คเกจไม่มีผลข้างเคียง (ในการประเมิน) และเปิดเผยเฉพาะการส่งออกเท่านั้น ซึ่งช่วยให้เครื่องมือเช่น webpack เพิ่มประสิทธิภาพการส่งออกซ้ำได้

ดูเพิ่มเติมที่: ตัวอย่าง sideEffects ข้อเสนอสำหรับการทำเครื่องหมายฟังก์ชันว่าบริสุทธิ์ eslint-plugin-tree-shaking

ไมโครมัด

source , umd:main

โปรดดูการระบุบิลด์ใน package.json

พัสดุ

source

ดูผู้ห่อพัสดุ/พัสดุ#1652

@std/esm

@std/esm

นักพัฒนามีความคิดเห็นที่ชัดเจนในทุกเรื่อง เพื่อรองรับ @std/esm อนุญาตให้ปลดล็อคคุณสมบัติพิเศษด้วยฟิลด์ "@std/esm" หรือ "@std":{"esm":{}} ใน package.json ของคุณ

ที่มา: @std/esm Unlockables

jspm

jspm

คุณสามารถเขียนคุณสมบัติแพ็คเกจทั้งหมดที่ฐานของ package.json หรือหากคุณไม่ต้องการเปลี่ยนคุณสมบัติที่มีอยู่ซึ่งคุณต้องการใช้โดยเฉพาะสำหรับ npm คุณสามารถเขียนการกำหนดค่าเฉพาะ jspm ของคุณภายในคุณสมบัติ jspm ของ package.json และ jspm จะใช้ตัวเลือกเหล่านี้เหนือตัวเลือกการกำหนดค่าระดับรูท

ตัวอย่างเช่น: 

{
  "name" : " my-package " ,
  "jspm" : {
    "main" : " jspm-main "
  }
}

ดูข้อมูลจำเพาะแบบเต็ม

ignore

หากมีไฟล์หรือโฟลเดอร์เฉพาะเจาะจงที่จะละเว้น ก็สามารถแสดงรายการเหล่านั้นในอาร์เรย์ได้

format

ตัวเลือกคือ esm , amd , cjs และ global

เมื่อโหลดโมดูลจาก npm รูปแบบโมดูลจะถือเป็น cjs ตามค่าเริ่มต้น และไม่มีการรันการตรวจจับอัตโนมัติ หากต้องการโหลดโมดูลในรูปแบบอื่น คุณจะต้องแทนที่คุณสมบัตินี้ด้วยตนเอง

ปัจจุบันรูปแบบโมดูล esm (โมดูล ECMAScript) ไม่ได้ใช้ใน package.json

registry

jspm เข้าใจการขึ้นต่อกันในบริบทของรีจิสตรี

เมื่อโหลดแพ็กเกจจาก npm jspm จะตั้งค่ารีจิสทรีเริ่มต้นเป็น npm และปฏิบัติต่อการอ้างอิงตามนั้น

เมื่อโหลดแพ็กเกจจาก GitHub คุณสมบัติการขึ้นต่อกันจะถูกละเว้นโดยไม่มีคุณสมบัติรีจิสทรีอยู่ เนื่องจาก jspm ไม่มีทางรู้ได้ว่าการขึ้นต่อกันมีความหมายอย่างไรสำหรับ repos GitHub ที่มีอยู่

การตั้งค่าคุณสมบัติรีจิสทรียังกำหนดวิธีที่ jspm ตีความแพ็คเกจอีกด้วย ตัวอย่างเช่น แพคเกจ GitHub ที่มี registry: "npm" จะถูกตีความว่าเป็น CommonJS และคุณสมบัติการสนับสนุน เช่น ไดเร็กทอรีและ JSON ที่ต้องการ พร้อมด้วยการรับการขึ้นต่อกันจาก npm เหมือนกับว่าได้รับการติดตั้งจากตำแหน่งข้อมูล npm ตั้งแต่ต้นเลย

แพ็คเกจบน GitHub ที่มีคุณสมบัติรีจิสทรีตั้งค่าเป็น registry: "jspm" จะมีการอ้างอิงที่ถือเป็นการอ้างอิงสไตล์ jspm

shim

แพ็คเกจที่เขียนเป็น globals จำเป็นต้องมีการกำหนดค่าชิมเพื่อให้ทำงานได้อย่างถูกต้องในสภาพแวดล้อมแบบโมดูลาร์ หากต้องการชิมไฟล์ some/global.js ภายในแพ็คเกจ เราสามารถเขียนได้: 

{
  "shim" : {
    "some/global" : {
      "deps" : [ " jquery " ],
      "exports" : " globalExportName "
    }
  }
}

ทั้ง deps และ exports เป็นทางเลือก

exports จะถูกตรวจพบโดยอัตโนมัติโดยตัวโหลด SystemJS เหมือนกับโกลบอลใดๆ ที่เขียนโดยสคริปต์ ในกรณีส่วนใหญ่ การตรวจจับนี้จะทำงานได้อย่างถูกต้อง

รูปแบบทางลัดของ "some/global": ["jquery"] ก็รองรับเช่นกัน หากไม่มี exports

map

การกำหนดค่าแผนที่จะเขียนใหม่ภายในต้องชี้ไปที่โมดูลภายในหรือภายนอกที่แตกต่างกัน

พิจารณาแพ็คเกจที่มีการพึ่งพาของตัวเอง dep อยู่ที่ third_party/dep อาจมีคำสั่ง need ภายในบางอย่างเช่น: 

  require ( 'dep' ) ;

เพื่อที่จะใช้เวอร์ชันท้องถิ่น เราสามารถเขียน: 

{
  "map" : {
    "dep" : " ./third_party/dep "
  }
}

นอกจากนี้ยังอาจมีประโยชน์ในการอ้างอิงแพ็คเกจด้วยชื่อของตัวเองภายในโมดูลย่อย: 

{
  "map" : {
    "thispackage" : " . "
  }
}

จากนั้นเราสามารถกำหนดความต้องการภายในเพื่อ import 'thispackage/module' ได้อย่างถูกต้อง

การกำหนดค่าแผนที่ยังสามารถอ้างอิงโมดูลย่อยการพึ่งพาได้

นอกจากนี้เรายังสามารถแยกโมดูลทั้งหมดได้โดยการแมปโมดูลเหล่านั้นกับโมดูลว่าง: 

{
  "map" : {
    "jquery" : " @empty "
  }
}

ค่าที่ส่งคืนจะเป็นวัตถุโมดูลที่ไม่มีการส่งออก

เบราว์เซอร์

browserify.transform

เอกสารอยู่ที่นี่

สร้างแอป React

proxy

ผู้คนมักจะให้บริการแอป Front-End React จากโฮสต์และพอร์ตเดียวกันกับการใช้งานแบ็กเอนด์

แหล่งที่มา: คำขอ Proxying API อยู่ระหว่างการพัฒนา

homepage

ที่มา: การสร้างเส้นทางสัมพัทธ์

บาเบล

babel

ดูปัญหานี้

เอสลินท์

eslintConfig

ล้อเล่น

jest

{
  "jest" : {
    "verbose" : true
  }
}

ที่มา: jest docs

สไตล์ลินท์

stylelint

โปรดดู: ตัวโหลดการกำหนดค่าใหม่

ขีดจำกัดขนาด

size-limit

หากคุณใช้ไลบรารีนี้ คุณสามารถกำหนดการกำหนดค่าใน package.json : 

{
  "size-limit" : [
    {
      "limit" : " 9 KB " ,
      "path" : " index.js "
    }
  ]
}

ที่มา: ขนาดจำกัด

พีเอ็มเมตริก

pwmetrics

คุณระบุตัวเลือกใน package.json : 

{
  "pwmetrics" : {
    "url" : " http://example.com/ " ,
    "expectations" : {
      "ttfcp" : {
        "warn" : " >=1500 " ,
        "error" : " >=2000 "
      }
    }
  }
}

ตัวเลือกที่มีทั้งหมดอยู่ที่นี่

ที่มา: pwmetrics

เอวา

ava

ตัวอย่าง: 

 "ava" : {
  "require" : [ " @std/esm " ]
}

ที่มา: ava

นิวยอร์ก

nyc

ตัวอย่าง: 

 "nyc" : {
  "extension" : [ " .js " , " .mjs " ],
  "require" : [ " @std/esm " ]
}

ที่มา: NYC

อื่น

preferGlobal

เลิกใช้แล้ว

ตัวเลือกนี้ใช้เพื่อทริกเกอร์คำเตือน NPM แต่จะไม่เตือนอีกต่อไป มีไว้เพื่อวัตถุประสงค์ในการให้ข้อมูลเท่านั้น ตอนนี้ขอแนะนำให้คุณติดตั้งไบนารีใดๆ ให้เป็น devDependencies ภายในเครื่องทุกที่ที่เป็นไปได้

style

คุณลักษณะ style ใน package.json มีประโยชน์สำหรับการนำเข้าแพ็คเกจ CSS ข้อเสนออยู่ที่นี่

สนับสนุนโดย: พัสดุ, npm-less, rework-npm, npm-css

ดูเพิ่มเติมที่: istf-spec

less

เหมือนกับ style แต่ราคาน้อยกว่า

สนับสนุนโดย: npm-less

แพ็คเกจ CommonJS

คุณสมบัติที่สงวนไว้

ฟิลด์ต่อไปนี้สงวนไว้สำหรับการขยายในอนาคต: build , default , email , external , files , imports , maintainer , paths , platform , require , summary , test , using , downloads , uid

ฟิลด์ต่อไปนี้สงวนไว้สำหรับการลงทะเบียนแพ็คเกจเพื่อใช้ตามดุลยพินิจ: id , type

คุณสมบัติทั้งหมดที่ขึ้นต้นด้วย _ หรือ $ ยังสงวนไว้สำหรับการลงทะเบียนแพ็คเกจเพื่อใช้ดุลยพินิจของตน

ที่มา: วิกิ CommonJS

เจเอสมาตรฐาน

standard

Standard JS เป็นแนวทางสไตล์ JavaScript, linter และตัวจัดรูปแบบ คุณสามารถเพิ่มคุณสมบัติบางอย่างให้กับ package.json เช่น parser , ignore , globals , plugins

ตัวอย่าง: 

 "standard" : {
  "parser" : " babel-eslint " ,
  "ignore" : [
    " **/out/ " ,
    " /lib/select2/ " ,
    " /lib/ckeditor/ " ,
    " tmp.js "
  ]
}

ดูเพิ่มเติม: มาตรฐาน JS

ขยาย
ข้อมูลเพิ่มเติม
แอปที่เกี่ยวข้อง
แนะนำสำหรับคุณ
ข้อมูลที่เกี่ยวข้อง ทั้งหมด