Mihaela M
5f3892f2c1
Mirror the shared Swift rules canon (rules-swift, commit 4ebb892) into docs/rules-swift/ as a read-only reference alongside the repo's tailored docs/rules/. PROVENANCE.md records the source, commit, and what was included or excluded; the upstream repo's own VCS, CI, and lint tooling is omitted as machinery rather than rule content. Exclude the vendored tree from the style gate (scripts/check-style.sh) and the pre-commit hook: the canon's enforcement docs quote the forbidden attribution phrases to define them, the same reason the repo's own enforcement files are already excluded.
1.2 KiB
1.2 KiB
Build Performance Benefits
Why ExtremePackaging pays off in build time. Rationale, not rule. Read once for context.
Incremental Compilation
With ExtremePackaging:
- Change AppFont → Only AppFont rebuilds
- Change AppComponents → Only AppComponents + dependent targets rebuild
- Change SharedModels → More rebuilds (foundation layer), but still isolated
Without ExtremePackaging:
- Change any file → Entire monolith rebuilds
Parallel Builds
Build Graph (simplified):
SharedModels ─┬─> ApiClient ─┬─> AuthFeature ──> iosApp
│ │
└─> AppTheme ───┴─> AppFeature ───┘
SPM builds in parallel:
[SharedModels, AppFont] → [ApiClient, AppTheme, SharedViews] → [AuthFeature, AppFeature] → [iosApp]
SPM automatically parallelizes independent package builds.
CI/CD Optimization
# A CI runner can cache per-package
stages:
- build-foundation
- build-infrastructure
- build-features
- build-apps
build-foundation:
script:
- swift build --product SharedModels
- swift build --product AppTheme
# Cache: Only rebuild if foundation changed