สิ่งที่ต้องพึ่งพาแบบเพียร์และการตัดต้นไม้

ข้อกำหนดร่วมใช้ประกาศแพ็กเกจที่ไลบรารีของคุณต้องการ แต่คาดหวังให้ผู้ใช้เป็นผู้จัดหา ใน package.json ของไลบรารี React ควรอยู่ใน peerDependencies ไม่ใช่ dependencies เมื่อผู้ใช้ติดตั้งไลบรารีของคุณ npm/yarn จะไม่ติดตั้ง React ให้อัตโนมัติ เพราะแอปของผู้ใช้มี React อยู่แล้ว และไลบรารีของคุณจะแชร์อินสแตนซ์นั้น

หาก React อยู่ใน dependencies ของไลบรารี npm อาจติดตั้ง React อีกชุดไว้คู่กับ React ของผู้ใช้ การมีอินสแตนซ์ React สองชุดในแอปเดียวกันจะทำให้ฮุกทั้งหมดทำงานผิดพลาดพร้อมข้อผิดพลาด "Invalid hook call" เมื่อประกาศ React เป็น peerDependency คุณกำลังบอก npm ว่า "ฉันต้องใช้ React แต่ให้ใช้ชุดที่ผู้ใช้มีอยู่แล้ว"

ข้อกำหนดร่วมบางรายการอาจเป็นตัวเลือกได้ เช่น ไลบรารีที่รองรับทั้ง styled-components และ CSS Modules ให้ทำเครื่องหมายข้อกำหนดร่วมที่เป็นตัวเลือกด้วย peerDependenciesMeta: { 'styled-components': { optional: true } } npm จะไม่แจ้งเตือนผู้ใช้เมื่อไม่มีข้อกำหนดร่วมที่เป็นตัวเลือก แต่ยังสามารถจัดเตรียมชนิดข้อมูล TypeScript ได้เมื่อมีการติดตั้งแพ็กเกจที่เป็นตัวเลือก

ฟิลด์ sideEffects ใน package.json จะบอกตัวรวมบันเดิลว่าไลบรารีของคุณปลอดภัยสำหรับการตัดส่วนที่ไม่ใช้งานหรือไม่ การตั้งค่า "sideEffects": false จะบอก webpack, Rollup และเครื่องมือที่คล้ายกันว่า การนำเข้าโมดูลใด ๆ จากไลบรารีของคุณไม่ก่อให้เกิดผลข้างเคียง ดังนั้นจึงสามารถลบการส่งออกที่ไม่ได้ใช้งานทั้งหมดออกจากบันเดิลของผู้ใช้ได้อย่างปลอดภัย

การนำเข้า CSS เป็นผลข้างเคียงที่พบได้ทั่วไป เพราะจะฉีดสไตล์ลงในหน้าเว็บเมื่อมีการนำเข้า หากไลบรารีของคุณนำเข้าไฟล์ CSS ให้ตั้งค่า "sideEffects": ["*.css", "*.scss"] เพื่อบอกตัวรวมบันเดิลว่าไฟล์ JS สามารถตัดส่วนที่ไม่ใช้งานได้อย่างปลอดภัย แต่ไฟล์ CSS ต้องรวมไว้เสมอเมื่อมีการนำเข้า

เพื่อให้การตัดส่วนที่ไม่ใช้งานมีประสิทธิภาพสูงสุด ให้ส่งออกแต่ละคอมโพเนนต์เป็นการส่งออกแบบมีชื่อจากไฟล์ของตัวเอง ใน index.ts ให้ส่งออกทุกอย่างซ้ำอีกครั้ง: export { Button } from './Button' เมื่อผู้ใช้นำเข้าเฉพาะ Button ตัวรวมบันเดิลก็สามารถลบคอมโพเนนต์อื่นทั้งหมดออกได้ ไฟล์รวมการส่งออกซ้ำช่วยให้ใช้รูปแบบนี้ได้

ใช้ bundlejs.com เพื่อทดสอบการตัดส่วนที่ไม่ใช้งาน โดยวางคำสั่งนำเข้าของคุณลงไป แล้วระบบจะรายงานขนาดบันเดิลจริง แพ็กเกจ npm size-limit ช่วยให้คุณกำหนดงบประมาณขนาดไว้ใน package.json และทำให้ CI ล้มเหลวหากขนาดการนำเข้าเกินขีดจำกัด: "size-limit": [{ "path": "dist/index.js", "limit": "10 KB" }]

กำหนดงบประมาณขนาดสำหรับการนำเข้าไลบรารีของคุณ เรียกใช้ npx size-limit ใน CI เพื่อบังคับใช้ หากเห็นผลกระทบของบันเดิลเพิ่มขึ้นเรื่อย ๆ แสดงว่าขอบเขตกำลังขยายเกินจำเป็น ไลบรารีคอมโพเนนต์ที่มุ่งเน้นเฉพาะทางควรควบคุมการนำเข้าคอมโพเนนต์แต่ละรายการให้อยู่ต่ำกว่าไม่กี่กิโลไบต์ แจ้งเตือนเมื่อเกิดการถดถอยก่อนที่จะส่งผลถึงผู้ใช้

หลีกเลี่ยง styled-components และ Emotion ในไลบรารีคอมโพเนนต์ที่คุณตั้งใจจะแจกจ่าย โซลูชัน CSS-in-JS ขณะทำงานเหล่านี้กำหนดให้ผู้ใช้ติดตั้งไลบรารีและเวอร์ชันเดียวกัน ซึ่งก่อให้เกิดความขัดแย้งของข้อกำหนดร่วม แม้ผู้ใช้จะใช้ Tailwind หรือ CSS ธรรมดา ก็ยังต้องรวมรันไทม์ CSS-in-JS ไว้ในบันเดิล ควรใช้ CSS Modules ซึ่งคอมไพล์เป็น CSS ธรรมดาในเวลาสร้างแทน

CSS Modules ทำงานได้ดีในไลบรารีเมื่อใช้ร่วมกับตัวรวมบันเดิลที่ประมวลผล CSS Modules ได้ tsup และ Rollup สามารถฝังผลลัพธ์ของ CSS Modules เป็นชื่อคลาสที่มีขอบเขตได้ ผู้ใช้ไม่จำเป็นต้องกำหนดค่าใด ๆ เพราะสไตล์จะถูกกำหนดขอบเขตและรวมอยู่ในบันเดิล JS แล้ว หรืออยู่ในไฟล์ CSS แยกต่างหากที่ถูกนำเข้า

เครื่องมือที่ใช้ในการพัฒนาของคุณเอง เช่น tsup, TypeScript, ไลบรารีการทดสอบ และ Storybook ควรอยู่ใน devDependencies เพราะจำเป็นเฉพาะระหว่างการพัฒนา และจะไม่ถูกรวมในการติดตั้ง npm ของผู้ใช้ React ควรอยู่ทั้งใน peerDependencies ซึ่งเป็นข้อกำหนดขณะรัน และใน devDependencies ซึ่งจำเป็นสำหรับการคอมไพล์และทดสอบไลบรารีของคุณภายในเครื่อง

การตั้งค่า "sideEffects": false ใน package.json ของไลบรารีสื่อสารอะไรกับตัวรวมบันเดิล

ประกาศ React ไว้ใน peerDependencies (ไม่ใช่ dependencies) เพื่อให้ผู้ใช้แชร์อินสแตนซ์ React ของแอปตนเอง sideEffects: false เปิดใช้การตัดส่วนที่ไม่ใช้งานของไลบรารีได้อย่างเต็มที่ ใช้ sideEffects: ['*.css'] เพื่อป้องกันไม่ให้การนำเข้า CSS ถูกลบ การส่งออกแบบมีชื่อจากไฟล์แต่ละไฟล์ช่วยให้การตัดส่วนที่ไม่ใช้งานมีความละเอียดสูงสุด บังคับใช้งบประมาณขนาดด้วย size-limit ใน CI และเลือกใช้ CSS Modules แทน CSS-in-JS ในไลบรารี เพื่อหลีกเลี่ยงความขัดแย้งของข้อกำหนดร่วม