การสร้าง Package Composer ของตัวเอง

การสร้าง Package Composer ของตัวเอง

หลังจากที่เราได้เรียนรู้การใช้งาน Composer ในการจัดการ Dependencies ของโปรเจกต์ PHP ของเราแล้ว ในบทนี้ เราจะมาดูวิธีการสร้าง Package Composer ของตัวเอง ซึ่งจะช่วยให้เราสามารถแบ่งปันโค้ดที่เราเขียนให้กับคนอื่น หรือนำโค้ดที่เราเขียนไว้กลับมาใช้ใหม่ในโปรเจกต์อื่นๆ ได้อย่างง่ายดาย

Package Structure

ก่อนที่เราจะเริ่มสร้าง Package Composer เราต้องทำความเข้าใจโครงสร้างของ Package Composer ก่อน โดยโครงสร้างพื้นฐานของ Package Composer จะประกอบด้วย:

• `composer.json`: ไฟล์ที่สำคัญที่สุด ซึ่งเป็นไฟล์ที่กำหนดข้อมูลเกี่ยวกับ Package เช่น ชื่อ, คำอธิบาย, Dependencies, Autoloading และอื่นๆ
• `src/`: โฟลเดอร์ที่เก็บ Source Code ของ Package
• `tests/` (Optional): โฟลเดอร์ที่เก็บ Unit Tests ของ Package
• `README.md` (Optional): ไฟล์ที่อธิบายวิธีการใช้งาน Package
• `LICENSE` (Optional): ไฟล์ที่ระบุ License ที่ใช้สำหรับ Package

ตัวอย่างโครงสร้าง Package:

my-package/
├── composer.json
├── src/
│   └── MyClass.php
├── tests/
│   └── MyClassTest.php
├── README.md
└── LICENSE

เหตุผลเชิงออกแบบ: การจัดโครงสร้าง Package ให้เป็นระเบียบช่วยให้ผู้ใช้งานเข้าใจ Package ได้ง่าย และทำให้การบำรุงรักษา Package เป็นไปได้ง่ายขึ้น การแยก Source Code ไว้ในโฟลเดอร์ `src/` และ Unit Tests ไว้ในโฟลเดอร์ `tests/` เป็นแนวปฏิบัติที่ดีที่ควรทำตาม

การสร้าง `composer.json`

ไฟล์ `composer.json` คือหัวใจหลักของ Package Composer ของเรา เราสามารถสร้างไฟล์นี้ได้ด้วยการใช้คำสั่ง `composer init` หรือสร้างไฟล์ด้วยตัวเองและแก้ไขข้อมูลที่จำเป็น

ตัวอย่าง `composer.json`:

{
  "name": "your-vendor/my-package",
  "description": "A simple PHP package",
  "type": "library",
  "license": "MIT",
  "authors": [
    {
      "name": "Your Name",
      "email": "your.email@example.com"
    }
  ],
  "minimum-stability": "dev",
  "require": {
    "php": ">=7.4"
  },
  "autoload": {
    "psr-4": {
      "YourVendor\\MyPackage\\": "src/"
    }
  }
}

คำอธิบายแต่ละ Field:

• `name`: ชื่อของ Package ในรูปแบบ `vendor/package-name` (ต้องเป็น Unique)
• `description`: คำอธิบายสั้นๆ เกี่ยวกับ Package
• `type`: ประเภทของ Package (เช่น `library`, `project`, `metapackage`, `composer-plugin`)
• `license`: License ที่ใช้สำหรับ Package (เช่น `MIT`, `GPL-2.0-or-later`, `Apache-2.0`)
• `authors`: ข้อมูลเกี่ยวกับผู้เขียน Package
• `minimum-stability`: Stability ขั้นต่ำของ Package (เช่น `stable`, `RC`, `beta`, `dev`)
• `require`: Dependencies ที่ Package ต้องการ
• `autoload`: กำหนด Autoloading สำหรับ Package

เหตุผลเชิงออกแบบ: การเลือกชื่อ Package ที่มีความหมายและเป็น Unique ช่วยให้ผู้ใช้งานค้นหา Package ของเราได้ง่าย การกำหนด License ที่ชัดเจนช่วยให้ผู้ใช้งานทราบสิทธิ์ในการใช้งาน Package ของเรา การกำหนด `autoload` ช่วยให้ Composer สามารถโหลด Class ของเราได้โดยอัตโนมัติ

การกำหนด Autoloading ด้วย PSR-4

ในส่วนของ `autoload` เราจะใช้ PSR-4 ซึ่งเป็น Standard ที่กำหนดวิธีการ Mapping Namespace ไปยัง Directory

ในตัวอย่าง `composer.json` ด้านบน เรากำหนด:

"autoload": {
  "psr-4": {
    "YourVendor\\MyPackage\\": "src/"
  }
}

หมายความว่าทุก Class ที่อยู่ใน Namespace `YourVendor\MyPackage\` จะถูกโหลดจาก Directory `src/`

ตัวอย่างเช่น ถ้าเรามี Class ชื่อ `MyClass` อยู่ในไฟล์ `src/MyClass.php`:

<?php

namespace YourVendor\MyPackage;

class MyClass
{
  public function hello()
  {
    return 'Hello from MyPackage!';
  }
}

เราสามารถใช้งาน Class นี้ได้โดยไม่ต้อง `require` ไฟล์ `MyClass.php`:

<?php

require_once 'vendor/autoload.php';

use YourVendor\MyPackage\MyClass;

$myClass = new MyClass();
echo $myClass->hello(); // Output: Hello from MyPackage!

เหตุผลเชิงออกแบบ: PSR-4 เป็น Standard ที่นิยมใช้กันอย่างแพร่หลาย ทำให้ Code ของเราสามารถทำงานร่วมกับ Code อื่นๆ ได้ง่ายขึ้น การใช้ Autoloading ช่วยลดความซับซ้อนในการจัดการไฟล์ และทำให้ Code ของเราสะอาดขึ้น

Publishing to Packagist

หลังจากที่เราสร้าง Package Composer ของเราเสร็จแล้ว เราสามารถเผยแพร่ Package ของเราไปยัง Packagist ซึ่งเป็น Repository หลักของ Composer เพื่อให้คนอื่นๆ สามารถติดตั้งและใช้งาน Package ของเราได้

ขั้นตอนการ Publishing:

1. สร้าง Account บน Packagist: ถ้ายังไม่มี Account ให้สร้าง Account บน Packagist
2. สร้าง Repository บน GitHub (หรือ Gitlab, Bitbucket): สร้าง Repository สำหรับ Package ของเราบน GitHub (หรือ Gitlab, Bitbucket)
3. Commit และ Push Code: Commit และ Push Code ของ Package ของเราไปยัง Repository
4. Submit Package บน Packagist: ไปที่ Submit Package บน Packagist และใส่ URL ของ Repository ของเรา
5. รอการตรวจสอบ: Packagist จะทำการตรวจสอบ Package ของเรา และถ้าทุกอย่างเรียบร้อย Package ของเราจะถูกเผยแพร่บน Packagist

แนวปฏิบัติที่ดี: ก่อนที่จะ Publish Package ของเรา ควรตรวจสอบให้แน่ใจว่า Code ของเราทำงานได้อย่างถูกต้อง และมี Unit Tests ที่ครอบคลุม เพื่อให้ผู้ใช้งานมั่นใจในคุณภาพของ Package ของเรา

Versioning

Versioning เป็นสิ่งสำคัญในการจัดการ Package Composer เพราะจะช่วยให้ผู้ใช้งานสามารถเลือก Version ของ Package ที่ต้องการใช้งานได้ และช่วยให้เราสามารถปล่อย Update และ Fix Bugs ได้อย่างเป็นระบบ

Composer ใช้ Semantic Versioning (SemVer) ซึ่งเป็น Standard ที่กำหนดรูปแบบของ Version Number:

MAJOR.MINOR.PATCH

• MAJOR: มีการเปลี่ยนแปลงที่ไม่สามารถใช้งานร่วมกับ Version ก่อนหน้าได้ (Breaking Changes)
• MINOR: มีการเพิ่ม Functionality ใหม่ แต่ยังสามารถใช้งานร่วมกับ Version ก่อนหน้าได้
• PATCH: มีการแก้ไข Bugs แต่ไม่มีการเปลี่ยนแปลง Functionality

ตัวอย่าง Version Number:

• `1.0.0`: Version แรกของ Package
• `1.1.0`: มีการเพิ่ม Functionality ใหม่
• `1.0.1`: มีการแก้ไข Bugs
• `2.0.0`: มีการเปลี่ยนแปลงที่ไม่สามารถใช้งานร่วมกับ Version ก่อนหน้าได้

แนวปฏิบัติที่ดี: ควรใช้ Semantic Versioning อย่างเคร่งครัด เพื่อให้ผู้ใช้งานสามารถเข้าใจผลกระทบของการ Update Package ได้ง่าย และควรมี Release Notes ที่อธิบายการเปลี่ยนแปลงในแต่ละ Version

ตัวอย่าง: หากเราแก้ไข Bug ใน Package ของเรา เราควรเพิ่ม Version เป็น `1.0.1` หากเราเพิ่ม Functionality ใหม่ เราควรเพิ่ม Version เป็น `1.1.0` และหากเรามีการเปลี่ยนแปลงที่ไม่สามารถใช้งานร่วมกับ Version ก่อนหน้าได้ เราควรเพิ่ม Version เป็น `2.0.0`

ในบทนี้ เราได้เรียนรู้วิธีการสร้าง Package Composer ของตัวเอง ซึ่งจะช่วยให้เราสามารถแบ่งปันโค้ดที่เราเขียนให้กับคนอื่น หรือนำโค้ดที่เราเขียนไว้กลับมาใช้ใหม่ในโปรเจกต์อื่นๆ ได้อย่างง่ายดาย ในบทถัดไป เราจะมาดูวิธีการใช้ Composer Plugin เพื่อเพิ่ม Functionality ให้กับ Composer