Home

Awesome

carbon-addons-angular

Common Addons for Carbon Angular projects

This repo represents a collection of useful components and patterns that aren't codified in the core Carbon Design System or Carbon Components Angular.

Prefixes and folder structure

Largely TBD but in order to keep contributions sane there needs to be some logical organization of the folders and prefixes used in the components. Not all components and patterns will be common to each org, and some components may be duplicated with changes. There are a few ways to account for this.

food for thought:

|- src
  |- component // base implementation
  |- component-sterling // sterling specific implementation
  |- component-cloud // cloud specific implementation

|- src
  |- component // base implementation
    |- sterling // sterling specific implementation
    |- cloud // cloud specific implementation

This results in one package, with many entry points, and a lot of code that may not be needed by all consuming teams. There may also be some confusion around which components and modules are allowed to be used, since they're all available in one package. In some respects this is a positive, since it would encourage cross org code use, at the expense of potential inconsistencies.

There are several challenges associated with each approach presented:

Another option is to present the repo as a monorepo of related packages. This still achieves the goal of centralizing source changes, while also allowing teams the flexibility to publish breaking changes and other new versions as needed

|- packages
  |- addons
    |- src
	  |- component // base implementation
  |- addons-sterling
    |- src
	  |- component // sterling specific implementation
  |- addons-cloud
    |- src
	  |- component // cloud specific implementation

This results in multiple packages, but the consuming team will likely need to install two - carbon-addons-angular and carbon-addons-[org name here]-angular. Two dependencies instead of one, however this also reduces the amount of redundant code consumed, and potential confusion between different implementations (sterling teams should only use sterling or core, cloud teams should only use cloud or core). This does also increase the barriers to cross org code reuse, since a team would need to download another package, at the expense of stronger limits on which components can be used in the first place.

There are still some challenges with this approach:

Contributing

Quickstart

Pull request guidelines

Issues submission guidelines

Resources

Resources