Packages in our monorepo are grouped and named, based of ownership and reusability in the following way:

#Blocks

Independent components, stateless and without any special cases. Exception: Theme context.

• Priority: Few dependencies, reusability across applications.
• Example Packages: @blocks/icons, @blocks/ui, @blocks/theme
• Ownership: One team per package, mainly Helix.

#Segments

Rich Components, typically consisting of components from Blocks, mostly stateful. Application wide contexts.

• Priority: Reusability within an application.
• Example Packages: @segments/authentication, @segments/session, @segments/user-specific-content
• Ownership: One team per package, mainly Helix.

#Libraries

Components used across domains and owned by a feature team.

• Priority: Cross-Team Reusability.
• Example Packages: @libraries/navigation, @libraries/product-list, @libraries/cart
• Ownership: One team per package, mainly feature teams.

#Domains

Domain code that's only used in a domain and is owned by a feature team

• Priority: Autonomy of the teams.
• Example Packages: @domains/community, @domains/product-display, @domains/brand
• Ownership: One feature team per package.

#Applications

Entry points and global code that must not be imported.

• Example Packages: @applications/shop, @applications/design-system
• Ownership: Helix

#Commons

Config and definitions. No depenencies to other packages.

• Example Packages: ./build, ./development, ./docker
• Ownership: Helix

#Tools

Non-productive support code

• Example Packages: @tools/package-generator, @tools/testing-support-shop, @tools/documentation-support
• Ownership: Helix

#Package assignment

Packages can be created with the Package Generator

#Package rules