Elements Single Release

[alexkilgour]

What

Update Elements from publishing each component as a separate package to publishing the whole library together.

Why

Now that Elements is more mature this model of working simplifies many things about the design system and allows a much easier way of standardising across products.

Done when

• Remove any old/unused components
  • e.g. global-grid
• Update frontend-package-manager
• Stable design tokens
  • Context only for now
• Allow interdependency on components, any areas for consolidation
  • e.g create global-buttons
  • any other cases where we have duplication?
• Bundle in any major breaking changes to brand-context
  • e.g see Absolute design token values used in this PR
• Update all components to work with the latest brand-context
• Provide compiled assets in components (@alexkilgour working on atm)
• Review open issues in this repository
• Incorporate documentation into the toolkits repo
  • Make sure it is up to date
• Utility classes
  • Used in Components?
  • Use of !important or cascade layers
• Update playbook to reflect any changes to approach
• Switch from Travis to Github Actions
• Implement a component "playground" within the repo
• Darwin considerations: How do they impact this work? Do we need any special consideration for widgets?
• Complete technical documentation

Anything else

The above list is currently a work in progress to be discussed. There may be more.

• article on component versioning

[alexkilgour]

• Will probably need to "lock" the repo at some point to carry this out which means no updates to components
• May have to maintain older versioned components for a period until everyone is updated
• Some of these changes can be made ahead of time (before locking the repo)

[sturobson]

a few thoughts:

Github's Design System (Primer) was originally a single release. In ~2017 it went to a monorepo. In 2019 it started moving back to single release. Today it looks like it's slightly split. They have separate repos for: Tokens, CSS, and Components (in various languages). This is visualised in a diagram in their Design Tokens repo. I mention this as Sid (author of the blogpost listed) works at Github now.

This is similar to how Wikipedia do it also. They have a looser monorepo making use of noms workspaces.

Both of these examples have their own separate GH organisation to keep everything in (nice and tidy).

Wikimedia go one step further and include their documentation site. I think that's a good thing. I think it would be good for the existing toolkits to have a better tie to elements.

Thoughts on an "Elements" org? Something like:

elements-themes (brand-context)
elements-tokens (design tokens, currently inside of context)
elements-components (toolkits)
elements-docs (ux-elements-docs, elements-design-system, others)

(I've split out tokens separately as they will hopefully be informing the docs site, and have the potential to work with Figma (if digital design move to Figma) or Sketch (if Sketch opens up their API a little more).

[sturobson]

at some point should this be an front-end open space ticket to be discussed?

[alexkilgour]

at some point should this be an front-end open space ticket to be discussed?

Yep, it should be. A number of people are aware this is the overall plan and I don't think we will find opposition to the idea, but would be good to discuss once we have an idea of what needs to be done and what it will look like

[alexkilgour]

Thoughts on an "Elements" org?

This would simplify things from our perspective, but given how SN is managed on github I'm not sure we will be able to do this. Worth having the conversation though

[sturobson]

given how SN is managed on github I'm not sure we will be able to do this.

perhaps something similar to how Wikimedia handle it?

github.com/springernature/elements/
github.com/springernature/elements/elements-themes
github.com/springernature/elements/elements-tokens
github.com/springernature/elements/elements-components
github.com/springernature/elements/docs

[sturobson]

With a move to a single release, or set of releases I think we should look at the contribution model and move towards a roadmap of work.

[sturobson]

another benefit would be a smoother transition to @use and @forward in Sass (as @import is still set for deprecation)

[amyhupe]

Reviewed this in planning today - have assigned @sturobson as the owner so that we have one person responsible for tracking and updating this issue.

Stu - can you review the tasks on here and check they're all part of this. For tasks which aren't, but still need to be done, can you create separate issues for them and remove them from the checklist above?