🌿 Arbetsflöde

Denna sida beskriver våra konventioner för versionshantering, commits och release-processen.

Versionshantering

Vi använder en enkel branchstrategi med en main-branch som alltid ska vara i ett deploybart skick. Utveckling sker i feature- eller bugfix-brancher som sedan mergas in i main. Vi använder inte develop eller andra liknande brancher för att hålla det enkelt och för att passa ett arbetssätt med kontinuerlig integration och leverans (CI/CD).

---

📝 Conventional commits

Commits görs enligt conventional commits. Använd engelska, imperativ form, definiera type feat|docs|fix|refactor|test|chore|ops... för att avgöra vilken versionsändring du vill göra och scope (project, component) som rubrik för changelog.

Viktigt: Scope börjar alltid med ett av Nx-projekten (components, theme, docs, etc.) för att versionshanteringen ska fungera korrekt. Du kan lägga till flera scopes med kommatecken, t.ex. feat(components,button): ...

Exempel

feat(components, button): add new button variant   # Minor bump för components
fix(theme): fix button hover color                 # Patch för theme
docs: update contribution guide                    # Ingen bump

# Med body för mer kontext
fix(theme): prevent red color on button hover

Introduce new css variable to automatically
select style based on input type

Types och versionsändringar

Type	Beskrivning	Version
feat	Ny funktionalitet	Minor
fix	Buggfix	Patch
docs	Dokumentation	Ingen
refactor	Kodrefaktorering	Ingen
test	Tester	Ingen
chore	Underhåll	Ingen

Breaking changes och major-versioner

För att trigga en major-version, lägg till BREAKING CHANGE: i commit-meddelandets body:

feat(components, button): remove deprecated size prop

BREAKING CHANGE: The size prop has been removed. Use variant instead.

Ta aldrig bort funktionalitet direkt - deprecera först! Markera med @deprecated i koden och dokumentera i release notes. Ge användare minst en major-version att migrera innan borttagning.

Innan du skapar en PR, städa gärna commit-historiken med git rebase -i om du har många commits i din feature branch. Guide till git rebase.

---

🚀 Release

Release sker automatiskt via CI/CD när ändringar mergas till main-branchen.

Hur det fungerar

1. Automatiska versioner: När en pull request mergas till main analyserar Nx Release alla commits sedan senaste release och räknar fram rätt version baserat på conventional commits.

2. Publicering: Om någon package får en ny version publiceras den automatiskt till npm.

3. Changelog och taggar: Changelog uppdateras automatiskt och nya git-taggar skapas enligt formatet nx-project@version.

4. Dokumentation: Dokumentationswebben byggs och publiceras automatiskt med de senaste ändringarna.

Vad du behöver göra

• Följ conventional commits: Se till att dina commits följer conventional commits-standarden, eftersom det avgör vilken versionsändring som sker (major, minor, patch).
• Skapa en PR: Alla kan skapa pull requests, men Midas core-team ansvarar för granskning och merge.
• Invänta merge: När din PR godkänns och mergas till main sker resten automatiskt.

Du behöver inte köra några manuella release-kommandon. CI/CD-pipelinen hanterar hela releasen automatiskt! 🎉