Modules เชิงลึก

npm vs Go modules

ถ้าคุณรู้จัก npm ก็เท่ากับเข้าใจ Go modules ไปแล้ว 90% ทั้งสองระบบใช้ semantic versioning, lock file และ manifest file เหมือนกัน mental model จึง map กันได้ลงตัว — แต่กลไกเบื้องหลังต่างกันในจุดสำคัญ

// package.json
{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.18.2",
    "lodash": "^4.17.21"
  },
  "devDependencies": {
    "jest": "^29.0.0"
  }
}

// go.mod
module github.com/myorg/my-app

go 1.21

require (
    github.com/gin-gonic/gin v1.9.1
    github.com/stretchr/testify v1.8.4
)

// ไม่มี devDependencies แยกต่างหากใน Go
// deps ที่ใช้เฉพาะ test รวมอยู่ใน require;
// compiler ไม่รวมมันใน production binaries

go.mod — manifest

go.mod เทียบเท่า package.json มี field ที่ต้องมี 3 ตัว:

module github.com/myorg/my-app   ← module path (import prefix)
go 1.21                          ← minimum Go version
require (...)                    ← direct dependencies

จุดที่ต่างจาก package.json:

module path เป็น string คล้าย URL มักตรงกับ path ของ repo บน VCS
ไม่มี devDependencies dependency ทุกตัวอยู่ใน require แต่ Go linker จะรวมเฉพาะ package ที่ binary นั้น ๆ import จริง ๆ
ไม่มี syntax range แบบ ^ คุณ pin version แบบเป๊ะ ๆ (เช่น v1.9.1)

go.sum — lock file

go.sum เทียบเท่า package-lock.json เก็บ cryptographic hash ของทุก dependency แต่ละ version:

github.com/gin-gonic/gin v1.9.1 h1:4idEAncQnU5cB7BerypkHKpy7LtzLuviaCYD2h8zebo=
github.com/gin-gonic/gin v1.9.1/go.mod h1:hPrL7YrpYKXt5YId3A/Tnip5kqbEAP+KLuI3SUcPTeU=

แต่ละ dependency มี hash 2 บรรทัด:

h1:... — hash ของเนื้อหา module zip
/go.mod h1:... — hash ของเฉพาะไฟล์ go.mod

ทั้งคู่ต้องตรงกันทุกเครื่องและใน CI — go mod verify คอยตรวจให้ และคุณควร commit go.sum เข้า version control ด้วย (เหมือน package-lock.json)

คำสั่ง module ทั่วไป

# เริ่มต้น module ใหม่
go mod init github.com/myorg/my-app

# เพิ่ม dependency (อัพเดท go.mod + go.sum)
go get github.com/gin-gonic/[email protected]

# Upgrade ไป latest patch/minor
go get github.com/gin-gonic/gin@latest

# ลบ dependencies ที่ไม่ใช้
go mod tidy

# ตรวจสอบ modules ที่ download ทั้งหมด match go.sum
go mod verify

# แสดง direct + indirect dependencies ทั้งหมด
go list -m all

# แสดง versions ที่มีของ module
go list -m -versions github.com/gin-gonic/gin

Major version semantics

Go modules ฝัง major version ไว้ใน import path สำหรับ v2 ขึ้นไป นี่คือจุดที่ต่างจาก npm มากที่สุดจนหลายคนแปลกใจ:

// npm — ชื่อ package เดิม แค่ version ใหม่
// package.json
"dependencies": {
  "some-lib": "^3.0.0"  // v3, import เดิม
}
// import someLib from 'some-lib';  ← ไม่เปลี่ยน

// Go — v2+ เปลี่ยน import path
// go.mod
require github.com/some-lib/core v2.0.0+incompatible

// ถ้าไลบรารีมี /v2 module ที่เหมาะสม:
require github.com/some-lib/core/v2 v2.0.0

// imports ของคุณเปลี่ยน:
import "github.com/some-lib/core/v2"
// v1:  import "github.com/some-lib/core"
// v2:  import "github.com/some-lib/core/v2"

replace directive — local development

ตอนที่คุณ develop dependency ไปพร้อมกับ main module replace จะ map module path ไปยัง directory บนเครื่อง — เทียบเท่า npm link หรือ path แบบ file: ใน package.json:

require github.com/myorg/shared-lib v1.2.3

replace github.com/myorg/shared-lib => ../shared-lib

ลบ replace ออกก่อน commit ขึ้น production แล้วรัน go mod tidy ตามเพื่อเก็บกวาดให้เรียบร้อย

Vendoring

Vendoring คือการ copy dependency ทั้งหมดมาไว้ใน directory vendor/ ภายใน repo — มีประโยชน์กับ build แบบ air-gapped หรือเวลาต้องการรับประกัน reproducibility โดยไม่ต้องพึ่ง module proxy:

# สร้าง/อัพเดท vendor directory
go mod vendor

# Build โดยใช้เฉพาะ vendored deps (ไม่สนใจ module cache)
go build -mod=vendor ./...

# ตรวจสอบ vendor match go.sum
go mod verify

🟦 go.env และ GOFLAGS

คุณตั้งค่า GONOSUMCHECK, GONOSUMDB, GOPROXY และ GOFLAGS ได้ใน shell หรือผ่าน go env -w:

# ใช้ corporate module proxy
go env -w GOPROXY=https://proxy.corp.example.com,direct

# Disable sum database สำหรับ private repos
go env -w GONOSUMDB=github.com/myorg/*

# ใช้ vendor เสมอถ้ามี
go env -w GOFLAGS=-mod=vendor

Go workspaces (`go work`)

Workspace (เพิ่มเข้ามาใน Go 1.18) ให้คุณ develop หลาย module ที่พึ่งพากันได้พร้อมกัน โดยไม่ต้องใช้ replace directive — เทียบเท่า npm workspaces หรือ yarn workspaces:

// npm workspaces — package.json ที่ root
{
  "workspaces": [
    "packages/api",
    "packages/shared"
  ]
}

// Go workspaces — go.work ที่ repo root
go 1.21

use (
    ./api        // module: github.com/myorg/api
    ./shared     // module: github.com/myorg/shared
)

// ตอนนี้ api import shared ได้โดยตรงจาก disk
// ไม่ต้องใช้ replace directive

# เริ่มต้น workspace (สร้าง go.work)
go work init ./api ./shared

# เพิ่ม module อื่นใน workspace
go work use ./cli

# Sync go.work.sum (lock file สำหรับ workspaces)
go work sync

ปกติ go.work มักถูก git-ignore เพราะเป็นของอำนวยความสะดวกระดับ local ไม่ใช่ deployment artefact ถ้าจำเป็นก็ใช้ GOWORK=off เพื่อปิดใน CI ได้