ฉันแก้ไขการพัฒนา Windows แบบเนทีฟแล้ว

ฉันแก้ไขการพัฒนาแบบเนทีฟของ Windows: รายละเอียดที่สมบูรณ์ของสิ่งที่ใช้งานได้จริง

การพัฒนาแบบเนทีฟของ Windows ประสบปัญหาการแยกส่วนของ toolchain การพึ่งพาอาศัยกัน และสภาพแวดล้อมที่ไม่สอดคล้องกันมานานหลายปี — แต่หลังจากการทดสอบหลายเดือน ในที่สุดฉันก็พบเวิร์กโฟลว์ที่ขจัดความสับสนวุ่นวาย คู่มือนี้ครอบคลุมถึงสิ่งที่เสียหาย สิ่งที่ฉันได้ลอง และการตั้งค่าที่ตอนนี้ขับเคลื่อนบิลด์การผลิตของฉันโดยไม่ต้องใช้วิธีแก้ปัญหา WSL แม้แต่ครั้งเดียว

เหตุใดการพัฒนา Windows Native จึงเป็นฝันร้ายอยู่เสมอ?

คำตอบที่ตรงไปตรงมาก็คือ Windows ไม่เคยได้รับการออกแบบโดยมีนักพัฒนาเป็นพลเมืองหลัก ระบบที่ใช้ Unix รวบรวมการจัดการแพ็คเกจ เชลล์สคริปต์ และการแยกสภาพแวดล้อมไว้ใน DNA ตั้งแต่เริ่มต้น Windows ปิดกั้นสิ่งเหล่านี้มานานหลายทศวรรษ ทำให้เกิดปัญหาความขัดแย้งด้านรันไทม์ของ PowerShell, CMD, Chocolatey, Winget, MSVC และ PATH ที่ยุ่งเหยิงเป็นชั้นๆ และภัยพิบัติที่แปรผันของ PATH ที่อาจทำให้วิศวกรอาวุโสต้องหยุดชะงักในช่วงบ่าย

ใครก็ตามที่เคยทำงานในพื้นที่นี้คุ้นเคยกับอาการนี้: แพ็คเกจติดตั้งอย่างถูกต้องบนเครื่องหนึ่งและล้มเหลวในอีกเครื่องหนึ่ง เครื่องมือสร้างอ้างอิงเวอร์ชันคอมไพเลอร์ที่แตกต่างกันขึ้นอยู่กับปริมาณงาน Visual Studio ที่คุณติดตั้งครั้งล่าสุด และโปรเจ็กต์ Node.js ที่ทำงานได้อย่างสมบูรณ์ใน WSL2 จะส่งข้อผิดพลาด EPERM ที่เป็นความลับบนระบบไฟล์ดั้งเดิม กรณีเหล่านี้ไม่ใช่กรณีขอบ — เป็นประสบการณ์เริ่มต้นสำหรับนักพัฒนา Windows ส่วนใหญ่

กลไกหลักใดบ้างที่เสียหายจริง ๆ ในการตั้งค่าของฉัน?

หลังจากตรวจสอบสภาพแวดล้อมของฉันอย่างเป็นระบบ ฉันระบุสาเหตุหลักสามประการที่เป็นสาเหตุประมาณ 80% ของความล้มเหลวในการสร้างของฉันและความไม่สอดคล้องกันของสภาพแวดล้อม:

ไลบรารีรันไทม์ที่ขัดแย้งกัน: Microsoft Visual C++ Redistributable หลายเวอร์ชันอยู่ร่วมกันโดยไม่มีลำดับการแก้ไขที่ชัดเจน ทำให้เกิดความล้มเหลวในการค้นหา DLL ในโมดูลดั้งเดิม

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

ขาดการแยกสภาพแวดล้อมระดับโครงการ: ต่างจากเวิร์กโฟลว์ Unix ที่ไฟล์ .env และคำสั่งเชลล์เป็นพลเมืองชั้นหนึ่ง Windows ไม่มีกลไกที่สอดคล้องกันในการกำหนดขอบเขตตัวแปรสภาพแวดล้อมไปยังโครงการโดยไม่ต้องใช้เครื่องมือของบุคคลที่สาม

ข้อขัดแย้งในการสิ้นสุดบรรทัด Git: การจัดการ CRLF/LF แบบผสมระหว่างเครื่องมือ Windows ดั้งเดิมและไลบรารีข้ามแพลตฟอร์มทำให้การตรวจสอบล้มเหลวในไฟล์ล็อค ทำลายการติดตั้งที่ทำซ้ำได้

ข้อกำหนดการอนุญาตระดับสูงสำหรับ symlink: ตัวจัดการแพ็คเกจจำนวนมากอาศัยลิงก์สัญลักษณ์ ซึ่งบน Windows ต้องการโหมดนักพัฒนาหรือสิทธิ์ของผู้ดูแลระบบ — การตั้งค่าที่เครื่องขององค์กรส่วนใหญ่ปิดใช้งานตามนโยบาย

“ปัญหาไม่เคยอยู่ที่ว่า Windows ไม่สามารถพัฒนาแบบเนทิฟได้ — เป็นเพราะไม่มีใครรวบรวมเครื่องมือที่เหมาะสมเข้ากับการกำหนดค่าโดยเจตนา เมื่อคุณปฏิบัติต่อสภาพแวดล้อมการพัฒนาของคุณเป็นผลิตภัณฑ์ที่ต้องการการตัดสินใจทางสถาปัตยกรรม ทุกอย่างจะเปลี่ยนไป”

ฉันจะแก้ไขเวิร์กโฟลว์การพัฒนา Windows Native ได้อย่างไร?

การแก้ไขไม่ใช่เครื่องมือเดียวหรือสคริปต์วิเศษ มันเป็นการออกแบบสถาปัตยกรรมใหม่โดยเจตนาเกี่ยวกับวิธีการประกอบ กำหนดขอบเขต และบำรุงรักษาสภาพแวดล้อม รากฐานเริ่มต้นด้วยการเปิดใช้งานโหมดนักพัฒนาซอฟต์แวร์ในระดับระบบปฏิบัติการเพื่อปลดล็อกการสร้าง symlink โดยไม่มีระดับความสูง จากนั้น Scoop จะเข้ามาแทนที่ตัวติดตั้งแบบผสมผสานเฉพาะกิจ เนื่องจากทำงานทั้งหมดในพื้นที่ผู้ใช้ จัดเก็บรายการในการควบคุมเวอร์ชัน และจัดการการจัดการ shim อย่างหมดจด

สำหรับโปรเจ็กต์ Node.js โดยเฉพาะ การเปลี่ยนมาใช้ Volta เพื่อการจัดการเวอร์ชันจะขจัดข้อผิดพลาด EPERM ที่รบกวน NPM ทั่วโลก Volta สกัดกั้นการเรียกแบบไบนารีที่เลเยอร์ชิม และแก้ไขเวอร์ชันรันไทม์ที่ถูกต้องต่อโปรเจ็กต์โดยไม่ต้องแตะ PATH ของระบบ เมื่อรวมกับคีย์ .volta ที่คอมมิตใน package.json ความเท่าเทียมกันของสภาพแวดล้อมในเครื่องต่างๆ จะกลายเป็นแบบอัตโนมัติแทนที่จะเป็นแรงบันดาลใจ

ชิ้นสุดท้ายคือการนำระเบียบวินัย .env ระดับโครงการมาใช้ ซึ่งบังคับใช้โดย direnv พอร์ตไปยัง Windows ผ่านทาง Scoop — ทำให้มั่นใจว่าทุกโครงการมีบริบทสภาพแวดล้อมของตัวเองที่เปิดใช้งานในรายการไดเรกทอรีและล้างข้อมูลเมื่อออก

Related Posts

• เครื่องมือแซนด์บ็อกซ์บรรทัดคำสั่งที่รู้จักกันน้อยของ macOS (2025)
• ผู้บริหาร Waymo เผยบริษัทจ้างพนักงานระยะไกลในฟิลิปปินส์
• ระบบควบคุมภาพ Sony Jumbotron (1998) [pdf]
• วิศวกรซิลิคอนวัลเลย์ถูกฟ้องในข้อหาส่งความลับไปยังอิหร่าน