hashicorp / design-system Goto Github PK

For instances where design has requested animations, we should determine the approach to uniformly implement the animations.

For example, in the dropdown component, design has requested an animation for the chevron:

However, in the implementation, we're using a different icon based on open/closed state:

We should determine how we should accommodate everyone's requirements in a consistent way.

Outline the use case for the new icon.
We have a closed caption icon our video player. For DevDot we would like to replace the icons used on the existing player in order to be more consistent. We have everything we need except for a closed caption icon. Happy to use something else if you have other suggestions.

If there's a similar existing icon, why isn't it a good fit? Please describe.
Nothing really similar, we could house the CC options in the settings icon but I am not sure how much control we have. It would also require a bit of discovery work for users in order to find the CC controls.

Describe alternatives you've considered.
A button could work but would increase the height of the control bar.

Screenshots

Figma
Add links to the relevant Figma files where this icon is used, if possible.

Page with Learn's video player

Additional context
N/A

Outline the use case for the new icon.
We need a check/success icon that matches the sizing and balance of the dot icons (dot/dot-half). These icons will show up together inline in a sidebar to show progress within a collection. Currently we are using a larger check icon on Learn but with the new design system it feels odd due to the smaller typography and spacing we are using.

If there's a similar existing icon, why isn't it a good fit? Please describe.
check-circle-fill but drawn at the same size as dot and dot-half.

Describe alternatives you've considered.
I have considered using check-circle-fill but it feels too large in comparison to the dot icons.

Screenshots

Figma
Add links to the relevant Figma files where this icon is used, if possible.

Additional context
Let me know if you have any other questions!

Comment: #170 (comment)

Creating an issue so we can decide/document.

One of the things we are missing from our documentation is what we intend to do with the design system.

I'm seeing comments in support chat about how we don't provide an exact 1:1 for some things, and we are continually needing to explain how this is purposeful- there are outdated or non-compliant (not accessible) designs that we do not intend to support. But we should say this on the scrappy site somehow, even if we have an RFC for the design system, because that seems to be where folks are looking for the answers.

As an alternative, It's possible that we need to add this section to each component page, instead. Maybe if we already know what previous "versions" of components we do not intend to support, we can have a section that explains this.

Either way, this will help us set expectations across the board and improve user support.

hashicorp/flight#79 (comment)

For reasons unknown, data-test-* selectors are not being stripped for production usage of ember-flight-icons.

cloud-ui

website docs in this repo

I'd like to be able to suggest a change to grammar or spelling in the GitHub UI and not face linter issues.

We should research if there's a way to run lint:hbs --fix in the CI process so I don't have to pull down locally for tiny changes.

This is only a nice-to-have.

The current code block theme does not provide sufficient color contrast.

We have decided to defer the discussion and decision about using px or rem in the Dropdown component min/max-width declarations to a new issue, to unblock the merging of the other PRs related to the Dropdown.
#202 (comment)

/cc @MelSumner @Dhaulagiri

Outline the use case for the new icon.

Users will soon be able to connect an entity from within the HashiCorp Platform (a cluster in the initial instance) to an external system (third-party log management applications) so that data will flow in real-time from HCP to the external providers. As part of the configuration flow, we’ll be offering users the ability to verify that 1️⃣ they’ve entered the correct information and 2️⃣ that the HCP is able to send data to the other system before committing what they’ve entered. We’ll need some way to help reinforce this testing functionality visually for users.

The description here is specific to its first use, but both @snehahash and @luoxuan00733 have mentioned that it might be useful for other similar networking-relating scenarios.

If there's a similar existing icon, why isn't it a good fit? Please describe.

I couldn’t find an existing icon that suggests verifying something that could either succeed or fail — the closest related ones seem to imply what the status is rather than checking to see what it could be.

Describe alternatives you've considered.

• Initially, there was no icon associated with this button, but given the upcoming recommendation for tertiary buttons, an icon will now be required.
• While most of the scenarios that have been compiled so far have been for testing connectivity between two a HashiCorp system and an external one, there might be other “pre-flight checking” scenarios that aren’t networking-related, and so perhaps a more generic “test” icon might be another alternative to one explicitly for network connections.

Screenshots

An icon-less “Test connection” button for audit log streaming

Figma

Audit log streaming designs

Additional context

N/A

So that the icons can scale responsively when the browser is zoomed or the base font size is changed in browser settings, I propose that we:

1. set the width and height CSS styles on the svg element using relative units. e.g. 1rem for the small/16px size and 1.5rem for the medium/24px size (or 1em/1.5em if you want it to always scale with any adjacent text)
2. validate the size argument to ensure that it's a valid size.

Note: the viewBox attribute can (and should) still use pixels.

Here is the relevant WCAG guideline: https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html

We need to add the following screenshot of the Design Guidelines to the Dropdown documentation on the scrappy site.

We had to make some minor adjustments to add optical balance to the icon so it fits better in the section where it will be used by Web Presence.

It's already been published in Figma and has been shared with @rayelder and violethuang (I'm not able to tag them here).

@didoo It is ready to sync and 🚀

Working with this addon in cloud-ui I came across the following situation in which the version of @hashicorp/ember-flight-icons was incorrect in a consuming app:

@hashicorp/[email protected] depends on
---> @hashicorp/[email protected]

cloud-ui has directly installed
---> @hashicorp/[email protected]

In practice @hashicorp/[email protected] is the one the consuming app actually used which caused behavior the component library was depending in 1.2.0 to not work correctly.

As per the design comp, add a sidebar to the design and engineering pages for easier navigation.

Outline the use case for the new icon.
We need an alert icon with a 4th shape. We have circle, triangle, and hexagon, we need another shape for color-blind users that can't rely on color.

If there's a similar existing icon, why isn't it a good fit? Please describe.
For compact alerts, alert-diamond and alert-diamond-fill icons are needed for accessibility purposes.

Describe alternatives you've considered.
alert-hexagon, but still similar to info.

Screenshots

Figma
Alert component (WIP)

Additional context
N/A

Outline the use case for the new icon.
We are needing an API (Application programming interface) icon which will appear in dropdown menus and on cards. We are using icons next to main sections on DevDot (API is one of a few) and want to create an identification pattern with our users.

If there's a similar existing icon, why isn't it a good fit? Please describe.
We have tried a few including terminal screen (what we use for CLI), tools (too generic and could be used elsewhere in the future), cloud (too generic) and settings (used elsewhere in the future). As API is one of the main buckets folks are looking to dig into we want it to have something custom that really speaks to what API is and is easily identifiable for folks.

Describe alternatives you've considered.
Looking around I saw the words API written out as well as a node with multiple branches to show off more of what an API can accomplish.

Screenshots

Figma
Link
Link

Additional context
I didn't draw anything but here are some examples of ones we like :)! Let us know if you want us to draw one.

Link

Link

Link

Context

In this Slack thread @ashleemboyer and @braydenlove have noticed that the CSS font-stacks for DevDot and HDS differ.

In CoreDevDotLayout (link):

--font-body: system-ui, -apple-system, blinkmacsystemfont, 'Segoe UI', roboto, helvetica, arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';
--font-display: system-ui, -apple-system, blinkmacsystemfont, 'Segoe UI', roboto, helvetica, arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';
--font-monospace: ui-monospace, menlo, consolas, ubuntu mono, monospace;

In HDS tokens (link):

--token-typography-font-stack-display: -apple-system, BlinkMacSystemFont, SF Pro Display, Segoe UI Display, Ubuntu, sans-serif;
--token-typography-font-stack-text: -apple-system, BlinkMacSystemFont, SF Pro Text, Segoe UI Text, Ubuntu, sans-serif;
--token-typography-font-stack-code: SF Mono, Consolas, Ubuntu Mono, monospace;

Discussing among us, we have decided it would be great to align them between the two codebases, so that DevDot can directly use the CSS variables/tokens provided by the design system

Proposed solution

Below is a list of changes that I am proposing.

Display/Text stack

• system-ui - I am proposing not to add it (so remove it from DevDot) - reason being is that it seems it may cause issues in some cases (apparently it caused issues in WebKit and Blink browsers with non-English languages, see here and here and here) - these are old issues, and we're not using non-English languages, but since it's just a replacement for -apple-system and BlinkMacSystemFont and we're already declaring it, there's no real need to add it
• -apple-system + BlinkMacSystemFont - in both DevDot and HDS, let's just leave them as they are
• SF Pro Display/Text - These are already in the HDS stack, I suggest we keep them so also DevDot will start to use them
• Segoe UI vs Segoe UI Display/Text - DevDot is using the first one, HDS the second one(s) - I could not find any reference to Segoe UI Display/Text online, probably it was me just looking at the design specs in Figma and using the description from there as font name, but is wrong (even the new variable font Segoe UI is just Segoe UI - so I am proposing to change HDS to use Segoe UI as in DevDot
• Roboto, Helvetica, Arial - they're not present in the HDS stack, so I am proposing to add them to the HDS stack
• Ubuntu - is not present in the DevDot stack, so I am proposing to add it to the DevDot stack
• Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol - I have not found many references online about why to add these, apart from this article on CSS Tricks - I suspect they're not needed anymore, but since they're pretty harmless in any case, I propose to add them to the HDS stack

Code stack

For the code stack things are much easier:

• ui-monospace - currently the support is very low so I am proposing to remove it from DevDot to simplify things
• SF Mono - this is missing from DevDot, so I am proposing to add it to DevDot
• Menlo - this is missing from HDS, so I am proposing to add it to HDS

/cc @heatherlarsen @braydenlove @cveigt + @ashleemboyer @hashicorp/design-systems what do you think?

In Safari:

For the disclosure component, clickOutside is not closing the container.

IS: Current behavior

Currently the medium (default) variant of the Hds::Button component has a computed/rendered height of 38px instead of 36 as in Figma.

Plus, the horizontal padding in the small variant is currently 16px but should be 12px according to Figma.

SHOULD BE: Expected behavior

The height for the medium variant should be 36px as expected in Figma.
The horizontal padding for the small variant should be 12px as expected in Figma.

Possible solution

The reason for this is that we are applying a min-height of 36px to the button (medium), but also a vertical padding that doesn't take into account the border width (`1px).
There are two options:

• use a calc() where we are defining the vertical padding
• slightly reduce the vertical padding (and add a comment explaining why that particular value)

In doing so, better to check also the large variant to see it has the same issue.

Outline the use case for the new icon.
We are needing a Plugins icon which will appear in dropdown menus and on cards. We are using icons next to main sections on DevDot (Plugins is one of a few) and want to create an identification pattern with our users.

If there's a similar existing icon, why isn't it a good fit? Please describe.
We are currently using box which isn't exactly right. I could see us using the box icon for things like packages or releases in the future and feel like plugins needs its own specific icon

Describe alternatives you've considered.
We considered socket but weren't sure if it was too on the nose. It is also just a play on words and might not be as memorable from a visual perspective. We could also have socket related content on DevDot in the future.

Screenshots

Figma
Link to figma

Additional context
A few icons I like from other systems

link
link

link

IS: Current behavior

Saw an HDS badge used in HCP that didn't look quite right, looked into it further and noticed the border-radius doesn't match the original designs in Figma so I checked the component in the scrappy site. Current border-radius in code appears to be 4px.

SHOULD BE: Expected behavior

Expected the border-radius to match Figma, which would be 5px.

Steps to reproduce

Can be seen in action in the sidebar of HCP or in the HDS scrappy website.

Possible solution

Update border-radius on all badges to be 5px.

The toggle button on the docs site could be refactored to be a bit cleaner.

Try to implement a refactor and see if it improves the code.

• remove extra selectors in CSS
• from code review: as I understand, there is only the declaration above for ds-toggle-16 so in that case you may remove the extra class in the selector, and just leave .ds-toggle-16-active
• from code review: suggestion: have more generic "toggle" sub-elements; decouple the behaviour and the presentation for the toggle. Create a more generic ds-toggle-control and ds-toggle-control-active (shared between the 16 and 24) and set the ds-toggle-control-active via JS based on the value of this.visibleIconSize.

Summary

Automate (as much as we can) z-index so we don't try to juggle/ remember the numbers.

Potential Solution

In sass, make a variable with a list of named z-index layers, and a function that accepts a name and returns what number it is in the list, that way you’re not trying to remember a number; when new things are added to the list, everything will adjust automatically:

$z: base, header, tooltip, dialog, alert;
.alert { z-index: z(alert); }

Animation question, extracted from hashicorp/flight#60

ZS: One thought I have is around enabling icon animations. It seems like a real challenge. An example might be the external-link icon animation we have on https://www.hashicorp.com/community. At present, we build this animation in the specific component (in this case a button / link component), by targeting specific parts of the SVG and animating them (eg https://github.com/hashicorp/react-components/blob/57720a9f36e6372d2ae38fc5701dc6c428fc971c/packages/button/styles/index.css#L53). One potential concern there is that if the markup in a Flight SVG changes, that could break our animations

Re: the animation concern: A potential solution there might be to give individual path parts of the SVGs ids that become part of the icon's contract to consumers. Eg maybe the external link icon would have the box-like path in one group with an id="box" and the two path s that make up the arrow in another group with id="arrow". Or maybe id isn't the right attribute to use :thinking_cat_face: In any case that could give us something to hook into to create CSS-based SVG animations.

ZS: here's a quick shot I took at the grouping-with-ids thing for external-link specifically:

Definitely more a "nice to have" than a strict requirement though (IMO). I suspect we would use Flight anyways and manually target the path elements we need to animate with like :nth-child or something (if it were to ship as-is, ie https://github.com/hashicorp/flight/blob/main/ember-flight-icons/public/icons/external-link-24.svg?short_path=1131512). Would just be very brittle.

Second animation example:

(we have a similar animation for a download icon, eg on https://www.consul.io in the top nav, that also targets the "arrow" part of the icon)

Jamie White reported a typo on the Breadcrumb documentation page.

I checked, and it was already fixed in Figma, along with a few minor updates; the image needs to get updated on the scrappy website.

Find the PNG file below:

Right now the docs are focused mostly on using the Ember component, assuming that anyone who wants to use the SVG itself is already well-versed in how to do that.

• Improve the dummy/app/templates/engineering.hbs file to include more examples of use cases.
• Any use case that we want to show users how to do correctly but don't actively support should have an extra note about that.

The Flight microsite is mostly responsive, but there are some thing we could do to clean it up, especially as it gets down to mobile sizes (device width <= 639px)

Things that could help improve the UI:

• Add Left/Right margin
• Add a fixed "back to top" button in the bottom right corner (Design needed?)
• Text alignment issues in quick links at the top ("Getting Started for...", etc)
• Improve Filter Results feature for smaller screen sizes (Design needed?)

Screenshots

For long-term success, we should discuss and unify around a format/syntax for JS comments.

I have been using https://jsdoc.app/
In other PRs I've seen format similar to what is in Structure

Since we are adding animated icons, it'd be helpful to outline this new category and add some examples to the design guidelines.

Updates:

• Add a new type under Available Types.
• Add a new item under best practices.

Copy updates:

• Animated
  Glyph with animated effect, e.g. spinning
  Used to show a transition between two states.
• Use animated icons to communicate activity happening in the background
  For example, when an object is updated, the 'loading' icon could appear after the save or update action is triggered, indicating that the changes are in progress.

Screenshots

I've made some scrappy GIFs, so we show them animated, not static.

Outline the use case for the new icon.
A fill version of the info icon.

If there's a similar existing icon, why isn't it a good fit? Please describe.
Compact alerts need filled icons. The only one available for information is outlined.

Describe alternatives you've considered.
None.

Screenshots

Figma
Alert component (WIP)

Additional context
N/A

As discussed with @MelSumner we want to have a consistent order for the declarations inside the backing class of the components:

tracked properties > everything else > actions, in that order. we can say that in the "Everything else" section, we want classNames to come last, but it's still before actions.

As a follow-up of this:

• @didoo will document this decision somewhere, so it's easy to refer to in the future
• @Dhaulagiri will investigate if this can be automated via a plugin (https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/order-in-components.md)

Originally posted by @MelSumner in #66 (comment)

Outline the use case for the new icon.
In Nomad, the user usually needs to look at the log page under task level to identify issue and troubleshoot. The log page has both stdout and stderr options. The current log page looks like this

However, one of the biggest pain point in the Nomad UI is that people have to click so many times to get to that page. So the idea is we can show a log icon in the allocation table, so people can get to the log page quickly. The new page looks like this

If there's a similar existing icon, why isn't it a good fit? Please describe.
There are similar icons in the system like what I have in the screenshot, but the engineers think that is for "terminal".
We also have an icon called "file-source", but it looks more like a file to me.
I think if we can have something like the file-source with the paper in the back, just change the "<>" into something else, that will work.
I also searched log icon in google, a lot of them has "log" text in the icon, altho i don't know if we have it small, will it be legible

Figma
Add links to the relevant Figma files where this icon is used, if possible.

So let me know if this is not clear enough, i am happy to brainstorm on the idea.

Outline the use case for the new icon.
Specific request by PMM stakeholder. Needed to support new solutions and industries listing pages.

Screenshots

Figma
Use case: Solutions / industries listing pages
Figma branch: re.add-government-icon

A nice enhancement could be to add dark mode for the docs site.

If possible
Given I am a consumer of the ember addon
And I do not specify an icon or the icon specified does not exist
I get a friendly error (or warning) notifying me that this needs to be corrected

In #109 we have added a footer to all the pages of the scrappy website.
In doing so we have added come containers that have width: 100% but also padding applied to them, so the final effect is that on smaller viewports the footer causes the page to overflow and have an horizontal scrollbar.

This is a follow-up task of hashicorp/design-system-components#180.

While working on the Disclose component, one issue that me and @MelSumner found was how to manage the case where it may be used with content that is not focusable. The focus-trap library that we're using (not directly, but via ember-focus-trap) triggers an error if the content that wraps the focus trap doesn't contain any focusable element.

We did multiple tests, but none of them successful (see below) so we decided to open a specific issue for that and move on with the component (both the Dropdown and the Breadcrumb/Truncate components will have focusable content, so it's not a problem yet, unless the Dropdown will need to support also non-focusable content).

Tests we did

Attempt hashicorp/design-system-components#1
@MelSumner did some tests in these two PRs and said that was working (but likely something else of the focus-trap was not working). When we tried to replicate her configuration, it didn't work.

• https://github.com/hashicorp/design-system-components/pull/175
• https://github.com/hashicorp/design-system-components/pull/167

Attempt hashicorp/design-system-components#2
We tried to use the option fallbackFocus as described in the focus-trap library (see https://github.com/focus-trap/focus-trap#createoptions), assigning the ID to different targets but it triggered the error anyway.

See this diff/patch: test2.patch.zip

Attempt hashicorp/design-system-components#3
We tried to add a @focusTrap prop that could control if the Disclosure should trap the focus in the content or not and conditionally render the content in HBS with/without trap.
The problem is that, because focus-trap handles three things at once (focus trapping + click outside + esc key) if we disable focus trap we have to use other modifiers for on-click-outside (eg this or this or @johncowen’s one) and for on-key-esc (eg. this or this).

See this diff/patch: test3.patch.zip

What next?

I think we have a few options to explore, and decide what works better for us:

• test again the fallbackFocus of the focus-trap and see if it works (eg. applying it to the whole content wrapper (.hds-disclosure__content) or one children (or the toggle itself?)
• test again the approach with the @focusTrap prop, managing differently the click-outside and the esc-key to dismiss the visibility (at a quick look, it would not require a massive refactoring).
• test the libraries/utilities already existing in Consul, developed by @johncowen, and see if in reality would make sense to extract them/port them into the design system and use them, making them part of the system itself (directly or with small modifications).
  • disclosure component
  • {{aria-menu}} modifier
    • source: https://github.com/hashicorp/consul/blob/main/ui/packages/consul-ui/app/modifiers/aria-menu.js
  • {{on-outside}} modifier
    • source https://github.com/hashicorp/consul/blob/main/ui/packages/consul-ui/app/modifiers/on-outside.js

/cc @MelSumner @hashicorp/design-systems

While working on #150 I noticed in the generated CSS for the Flight website (packages/flight-website/dist/assets/flight-website.css) that it contains two resets: one from Normalize and one from Tailwind. See flight-website.css.zip for the full CSS, while below a couple of screenshots show what I mean:

Normalize	Tailwind

We don't know what is the combined effect of these two. Maybe we should remove one of them? (probably normalize, since we're heavily relying on Tailwind on that website?)

/cc @MelSumner

Would be nice to add to the website:

• a favicon
• an og:image

I was trying to follow the explanation here to install a new package:

I've run this command in the root of the repository:

yarn workspace @hashicorp/design-system-components run ember install ember-style-modifier

But the results were not the expected ones:

• it created a yarn.lock file under the packages/components/ folder anyway (so it needs to be removed manually)
• it doesn't update the main yarn.lock file in the root

Animation question, extracted from hashicorp/flight#60

ZS: One thought I have is around enabling icon animations. It seems like a real challenge. An example might be the external-link icon animation we have on https://www.hashicorp.com/community. At present, we build this animation in the specific component (in this case a button / link component), by targeting specific parts of the SVG and animating them (eg https://github.com/hashicorp/react-components/blob/57720a9f36e6372d2ae38fc5701dc6c428fc971c/packages/button/styles/index.css#L53). One potential concern there is that if the markup in a Flight SVG changes, that could break our animations

Re: the animation concern: A potential solution there might be to give individual path parts of the SVGs ids that become part of the icon's contract to consumers. Eg maybe the external link icon would have the box-like path in one group with an id="box" and the two path s that make up the arrow in another group with id="arrow". Or maybe id isn't the right attribute to use :thinking_cat_face: In any case that could give us something to hook into to create CSS-based SVG animations.

ZS: here's a quick shot I took at the grouping-with-ids thing for external-link specifically:

Definitely more a "nice to have" than a strict requirement though (IMO). I suspect we would use Flight anyways and manually target the path elements we need to animate with like :nth-child or something (if it were to ship as-is, ie https://github.com/hashicorp/flight/blob/main/ember-flight-icons/public/icons/external-link-24.svg?short_path=1131512). Would just be very brittle.

Second animation example:

(we have a similar animation for a download icon, eg on https://www.consul.io in the top nav, that also targets the "arrow" part of the icon)

hashicorp/flight#241 introduces new design documentation around drawing the icons, which includes images/icons for various dimension values. Since these images/icons aren't purely decorative and do provide value to the user, we need to add alt text.

• icon-dimensions-helper-1.png maps to "Line length"
• icon-dimensions-helper-2.png maps to "Starting position - x and y coordinates"
• icon-dimensions-helper-3.png maps to "Corner radius"
• icon-dimensions-helper-4.png maps to "Stroke weight"

Screenshots

A side effect of observing this run of ember-flight-icons only failing for the ember try scenarios has revealed what I think is a subtle problem with how ember-try is working in our monorepo setup.

What is happening

ember-try is running yarn from within the given package which is not how the yarn workspace "works". The install should always happen at the root.

What should happen

ember-try runs yarn from the workspace root and then runs the actual scenarios from within the specific page.

Maybe a spike / epic? Bringing from Slack to an issue for tracking purposes.

@natmegs is looking to add icons like these numbered hexagons to cloud-ui :

From @dizzyup:

I was thinking maybe we could come up with a stack-like component that composes the base icons with a text label (this way we could also keep the shadow from the designs easily)

My thought was: maybe this will be an extension of FlightIcon, something like an isCustom param.

What happens now

When I put items into both the :toggle and :content named blocks, the :content container does not display over the existing content, but instead shoves the existing content down (which causes the item in the :toggle block to jump around).

What I expect

When the container is shown, it is shown over other content.

Would be great to standardize the way we write the integration tests.

Some things that may be improved/we have to decide:

• not clear how to test the existence of the element (at the moment we test that it has the right class name, is it correct?)
  • somewhere (Structure? CloudUI?) I have seen something like test('it renders' ... assert.ok(component.renders)
• in some cases we use it should render in others it renders
  • @amyrlam suggested to use the component name instead of it
• do we want spacing or not between the single tests (they're visually grouped using a // GROUP comment
• check that all the tests have
  • spacing
  • grouping
  • tests for text/content and for assertions (in the early tests maybe we didn't do)
• remove the .dom(this.element.querySelector('.[class]')) in favour of .dom('.[class]') (much simpler!)

/cc @hashicorp/design-systems

Originally posted by @didoo on https://github.com/hashicorp/design-system-tokens/issues/81 (can't transfer issue in GitHub UI, cause is from internal to public repo):

As a follow up of https://github.com/hashicorp/design-system-tokens/pull/79 (the second part)

In https://github.com/hashicorp/design-system-tokens/pull/79 we have added CSS helpers for the basic colors (foreground, page, surface, border). In the same PR we have decided to ignore old "semantic" colors (they're deprecated now) and for the "focus" colors (they're strictly related to a11y, we don't want consumers to mess up with them).

We have left out the palette colors and the product ("branding") colors, because we have to decide

• if we want to have CSS helpers also for these colors
• if yes, if we want to create all the combinations for foreground, surface and border

At some point today certain tests in the ember-flight-icons test suite stopped working. Example

/home/runner/work/design-system/design-system/packages/components/@hashicorp/ember-flight-icons/components/flight-icon.js: Cannot read properties of null (reading 'source')TypeError: /home/runner/work/design-system/design-system/packages/components/@hashicorp/ember-flight-icons/components/flight-icon.js: Cannot read properties of null (reading 'source')

This can be reproduced locally by doing this

yarn install --no-lockfile --non-interactive
cd packages/ember-flight-icons
yarn start

Because this seems to happen in scenarios where the current lockfile is not respected it stands to reason some upstream dependency changed in a way that breaks things. Why? Unknown right now..