59ed9bc044
Foundation for incremental sync: compute and store content hashes at update time so the future sync step can diff against deployed_hash to find what needs uploading to R2. - Migration 024: add content_hash, deployed_hash, content_changed_at columns to packages table - Extract internal/composer/ from internal/repository/ (format.go, serialize.go, hash.go) — pure functions for Composer serialization and hashing with no I/O - Add SerializePackage() for tagged/dev file splitting and HashVersions() for lightweight content hashing - Compute content_hash in update step after NormalizeAndStoreVersions; only advance content_changed_at when hash actually changes - Hash includes trunk_revision so dev-trunk SVN reference changes trigger re-sync - repository/ re-exports from composer/ for builder.go compatibility Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
19 lines
607 B
Go
19 lines
607 B
Go
package repository
|
|
|
|
import (
|
|
"github.com/roots/wp-packages/internal/composer"
|
|
)
|
|
|
|
// Re-export types and functions from the composer package for backwards compatibility
|
|
// with existing callers (builder.go, integration tests, etc.).
|
|
// These will be removed when builder.go is deleted in Phase 3.
|
|
|
|
type PackageMeta = composer.PackageMeta
|
|
|
|
var (
|
|
ComposerVersion = composer.ComposerVersion
|
|
ComposerName = composer.ComposerName
|
|
DownloadURL = composer.DownloadURL
|
|
VendorFromComposerName = composer.VendorFromComposerName
|
|
SlugFromComposerName = composer.SlugFromComposerName
|
|
)
|
