feat(status-light)!: migrate status-light to s2 styles and second-gen architecture #5800

marissahuysentruyt · 2025-10-10T21:01:42Z

Description

This PR migrates the status-light component to the second-generation architecture, creating a shared base class that both first-gen and second-gen implementations extend. This enables the component to work in both Spectrum 1 and Spectrum 2 contexts while sharing common logic.

Key changes

Created shared base class (@swc/core/components/status-light/StatusLight.base.ts) that contains common logic for both generations
Created shared types file (StatusLight.types.ts) defining variants for S1 and S2:
- S1 variants: semantic (neutral, info, positive, negative, notice, accent) + color (fuchsia, indigo, magenta, purple, seafoam, yellow, chartreuse, celery, cyan)
- S2 variants: semantic (neutral, info, positive, negative, notice) + color (all S1 colors plus pink, turquoise, brown, cinnamon, silver)
Refactored first-gen (first-gen/packages/status-light/src/StatusLight.ts) to extend the shared base class
- Maintains S1-specific disabled property (deprecated in S2)
- Uses S1-specific variant types
- Added deprecation warnings for S1 types/exports
Implemented second-gen (second-gen/packages/swc/components/status-light/StatusLight.ts) extending the shared base class
- Uses S2-specific variant types
- Removed disabled property (not supported in Spectrum 2)
- Added S2 Spectrum CSS styles
Enhanced stories with comprehensive examples for all variants and sizes
Fixed variant selectors for accent and cyan variants
Added size support with sizeMap decorator for consistent sizing across scales
Added tests for second-gen status light and a test for deprecation warnings in first-gen

Motivation and context

This migration is part of the broader effort to support Spectrum 2 design system while maintaining backward compatibility with Spectrum 1. By creating a shared base class, we reduce code duplication and ensure consistent behavior across both generations while allowing each to have generation-specific features and styling.

Related issue(s)

SWC-1260

Screenshots (if appropriate)

New stories for S2/second-gen:

Author's checklist

I have read the CONTRIBUTING and PULL_REQUESTS documents.
I have reviewed at the Accessibility Practices for this feature, see: Aria Practices
I have added automated tests to cover my changes.
I have included a well-written changeset if my change needs to be published.
I have included updated documentation if my change required it.

Reviewer's checklist

Includes a Github Issue with appropriate flag or Jira ticket number without a link
Includes thoughtfully written changeset if changes suggested include patch, minor, or major features
Automated tests cover all use cases and follow best practices for writing
Validated on all supported browsers
All VRTs are approved before the author can update Golden Hash

Manual review test cases

Pull down the repo to run locally.

First-gen status-light functionality

Navigate to the first-gen status-light Storybook
Verify all S1 variants render correctly:
- semantic: neutral, info, positive, negative, notice
- color: fuchsia, indigo, magenta, purple, seafoam, yellow, chartreuse, celery
Verify the missing S2 variants have been added
- semantic: accent
- color: cyan
  NOTE: these missing variants were an identified gap during the component analysis
Verify disabled state still works correctly and properly adds or removes aria-disabled
There should be no VRT diffs for the status light examples that were originally supported in Storybook. The only VRT diffs would include the missing accent and cyan variants.

Second-gen status-light functionality

Navigate to the second-gen status-light Storybook
Verify all S2 variants render correctly:
- semantic: neutral, info, positive, negative, notice (accent was deprecated)
- color: fuchsia, indigo, magenta, purple, seafoam, yellow, chartreuse, celery, cyan, pink, turquoise, brown, cinnamon, silver (5 new non-semantic colors)
Expect visual appearance matches Spectrum 2 design specifications

Shared base class validation

Verify both implementations properly extend the shared base class
Expect no TypeScript errors and proper type narrowing for each generation
Verify variant validation warnings appear in dev mode for invalid variants
- First-gen: Try adding an extra S2-only story to the S1 storybook. For example, add: <sp-status-light size="s" variant="brown">brown</sp-status-light>
- Confirm that a browser warning appears in the console:

Second-gen: Try adding an extra S1-only story to the S2 storybook. For example, add:

export const Disabled: Story = {
    render: () => html`
      <swc-status-light variant="accent" disabled>disabled</swc-status-light>`
};

Confirm that a browser warning appears in the console:

Replace the variant value with something valid for S2, then reconfirm the new disabled console warning appears in the browser:

Device review

Did it pass in Desktop?
Did it pass in (emulated) Mobile?
Did it pass in (emulated) iPad?

changeset-bot · 2025-10-10T21:01:46Z

⚠️ No Changeset found

Latest commit: 888651e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

- imports new types - adds the api overrides for color and semantic variants - adds documentation - ensures the disabled state is not supported in S2 and throws a warning - ensures the disabled property still adds the aria-disabled attribute for S1 - ensures the variants values are validated and throws a warning if not

github-actions · 2025-10-13T16:47:37Z

📚 Branch Preview

🔍 Visual Regression Test Results

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

Deployed to Azure Blob Storage: pr-5800

If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.

github-actions · 2025-10-13T16:50:55Z

Tachometer results

Currently, no packages are changed by this PR...

- imports new S2 types for colors and semantic variants - adds the api overrides - adds documentation and example usage - refactors template render to use CSS classes and classMap()

- imports new S1 types for colors and semantic variants - adds the api overrides and extra disabled property - adds documentation, deprecation notices, and example usage

marissahuysentruyt · 2025-10-14T19:38:32Z

first-gen/packages/status-light/src/StatusLight.ts

+    // ───────────────────────
+
+    /**
+     * @todo This property is deprecated in S2, and can be removed once we are no longer maintaining S1.


Whoops- should this be @deprecated instead?

Yes, I think we should just go ahead and deprecate this, with an appropriate customer-facing message, similar to the ones for the other deprecations in this file.

marissahuysentruyt · 2025-10-14T19:39:37Z

first-gen/packages/status-light/src/spectrum-status-light.css

 }

-.spectrum-StatusLight--accent:before {
+:host([variant="accent"]):before {


The 2 updates in the first-gen CSS correspond to the gaps that were identified in the component docs. Is it still in scope for me to correct these missing variants? It obviously introduces VRT diffs, so I'm not sure where or if or when we want to introduce those diffs.

Interesting! Without digging too deeply, it looks to me like these were just cases where our (now-retired) automatic conversion of Spectrum CSS styles to SWC styles was failing—i.e., these were just bugs. Does that seem right to you?

As a matter of principle, my preference would be to split these fixes out into a separate PR, with a changeset describing the fixes.

I think it makes sense personally but maybe we can also open PRs to fix it on main?

marissahuysentruyt · 2025-10-14T19:40:30Z

first-gen/packages/status-light/stories/status-light.stories.ts

 };

 export const s = (): TemplateResult => html`
+    <sp-status-light size="s" variant="accent">accent</sp-status-light>


Same question here- we found SWC was missing the accent and cyan variants that are defined for S1. Is it within the scope of this ticket to show those now for the first-gen stories?

Yeah—per my earlier comment, I'd prefer that this and the corresponding fixes be pulled out into a separate PR.

marissahuysentruyt · 2025-10-14T19:41:04Z

first-gen/packages/status-light/test/status-light.test.ts

        expect(el.getAttribute('aria-disabled')).to.equal('true');
    });
+
+    describe('dev mode warnings', () => {


I had Cursor help me with this- do we want tests for the dev warnings at all? Feedback no this is appreciated either way!

This seems like a good idea to me, but open to dissenting opinions (cc @rubencarvalho).

I think we do test for dev mode on other components so I think that makes a lot of sense to add here too. Check out this reference for an example:

spectrum-web-components/first-gen/packages/alert-banner/test/alert-banner.test.ts

Line 193 in ee5fdd5

it('should log dev warning when given invalid variant', async () => {

marissahuysentruyt · 2025-10-14T19:48:56Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+argTypes.variant = {
+    ...argTypes.variant,
+    name: 'Variant',
+    description:
+        'Changes the color of the status dot. The variant list includes both semantic and non-semantic options.',
+    type: { name: 'string', required: true },
+    table: {
+        type: { summary: 'string' },
+        defaultValue: { summary: 'info' },
+        category: 'Component',
+    },
+    control: { type: 'select' },
+    options: StatusLight.VARIANTS,
+};


Feel free to tell me to remove this and just follow what Badge is doing! This was the way I found that worked to populate more of the control table, but maybe that's not something we want to dive into right now. (and also this approach didn't really work with the default slot arg, sooo...it's not fool-proof 😆)

Our vision for where this is going is that pretty much everything populating the table will flow from our code (including JSDocs) all the way through to Storybook, with little to no need for manual intervention in the *.stories.ts files.

To the extent that's not happening yet, I'd like to see if we can diagnose and fix issues in our tooling pipeline.

Meanwhile, I'd like to see us take a light touch, making minor tweaks as needed to unblock / ease testing during development, but otherwise not striving to manually fill gaps between what's currently showing and where we'd eventually like to get.

Since we're not expecting customers to be referring to the 2nd-gen Storybook for some time yet, the rough edges shouldn't hurt anyone, and their continued presence should help incentivize us to address the root-cause issues in the tool chain! 😁

If I look at what you've done here and compare it to the equivalent of what's being done in Badge:

argTypes.variant = { ...argTypes.variant, control: { type: 'select' }, options: StatusLight.VARIANTS, };

...they seem essentially equivalent in terms of behavior, and your improvement to the description can be achieved by editing the JSDoc in component implementation, so I'd like to see us fall back to the lighter version. Does that make sense? Let me know if I'm missing anything significant.

(Ultimately, I'm hoping we don't even have to do this much augmentation—I think we should be able to dial in our tooling to the point where it all "just works.")

marissahuysentruyt · 2025-10-14T19:51:08Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+};
+
+// ────────────────────────
+//    HELPER FUNCTIONS


I pulled capitalize() and CONTAINER() from the other migrations, and then created a size map function for the labels in the size stories. This was totally personal preference, so I'm not offended if we don't like it and want to drop it.

marissahuysentruyt · 2025-10-14T19:52:09Z

second-gen/packages/swc/components/status-light/test/status-light.test.ts

Cursor pulled in the badge test patterns and created this status light test file. Is this something appropriate for the migration, or would you like me to separate this out into a different PR?

Technically speaking, tests weren't required for these Barebones component migrations.

I am neutral on whether we take these as part of this PR or pull them out and consider testing more holistically across the Barebones components.

@rubencarvalho, thoughts?

marissahuysentruyt · 2025-10-14T20:04:19Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+ * We may have to explicitly bind the args to the component (particularly
+ * helpful for the size property) so the Storybook controls work as expected.
+ * 
+ * i.e. render: (args) =>
+        html`<swc-status-light .size=${args.size} variant=${args.variant}
+            >${args['default-slot']}</swc-status-light
+        >`,


If this comment is too much/overkill, let me know. I did document this idea in #5798, as well.

The getStorybookHelpers function is supposed to automatically handle the bindings, but it's not working as expected for certain properties; in the case of size, I think it's probably because properties from mixins are not propagating as they should through the Custom Element Manifest generation process.

I see this falling into the same category I was discussing in my previous comment—our preferred option is to see if we can make our tooling "just work", so we don't have to manually bind templates in our stories. If we try that and fail, then I think we can fall back to something like this.

marissahuysentruyt · 2025-10-14T20:23:31Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+    args: {
+        ['default-slot']: 'Status light',
+        variant: 'info',
+        size: 'm',


Does this conflict with the noDefaultSize arg in StatusLightBase (for SizedMixin)? I don't have a good handle on the SizedMixin, but there is a default size defined in the design specs.

Maybe I need to do a Cursor dive into SizedMixin!

This is a good question! SizedMixin is not too complex, so the implications of noDefaultSize should be easy enough to reason about. Not having thought through the nuances, and without knowing the history, it's hard to say why SWC would be applying noDefaultSize if the design does, in fact, call for a default size, but I'm hopeful we'll be able to make sense of it.

Meanwhile, I would guess that there's no issue with having a default size from a Storybook perspective, even if there are legitimate technical reasons why noDefaultSize is the right choice from a SizedMixin point of view.

That said, for the sake of consistency in the way we're overriding args in our Barebones stories, I'd prefer that we insert these lines above the declaration of meta:

args['default-slot'] = 'Status light'; args.size = 'm';

...and then just refer to args in the meta declaration, rather than define it inline, e.g.:

const meta: Meta = { /* other props... */ args, };

castastrophe

This looks really great to me. Thanks for tackling this!

castastrophe · 2025-10-15T19:39:27Z

first-gen/packages/status-light/src/spectrum-status-light.css

 }

-.spectrum-StatusLight--accent:before {
+:host([variant="accent"]):before {


I think it makes sense personally but maybe we can also open PRs to fix it on main?

castastrophe · 2025-10-15T19:41:09Z

first-gen/packages/status-light/test/status-light.test.ts

        expect(el.getAttribute('aria-disabled')).to.equal('true');
    });
+
+    describe('dev mode warnings', () => {


I think we do test for dev mode on other components so I think that makes a lot of sense to add here too. Check out this reference for an example:

spectrum-web-components/first-gen/packages/alert-banner/test/alert-banner.test.ts

Line 193 in ee5fdd5

it('should log dev warning when given invalid variant', async () => {

castastrophe · 2025-10-15T19:43:11Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+argTypes.variant = {
+    ...argTypes.variant,
+    name: 'Variant',
+    description:
+        'Changes the color of the status dot. The variant list includes both semantic and non-semantic options.',
+    type: { name: 'string', required: true },
+    table: {
+        type: { summary: 'string' },
+        defaultValue: { summary: 'info' },
+        category: 'Component',
+    },
+    control: { type: 'select' },
+    options: StatusLight.VARIANTS,
+};


graynorton

This looks really good—nice work! 😊

Most of my comments are about places where you've gone above and beyond Barebones requirements in ways that I think we may either want to pull out into separate PRs or just hold off on for right now—let's discuss in the comment threads.

graynorton · 2025-10-15T18:35:22Z

first-gen/packages/status-light/src/spectrum-status-light.css

 }

-.spectrum-StatusLight--accent:before {
+:host([variant="accent"]):before {


Interesting! Without digging too deeply, it looks to me like these were just cases where our (now-retired) automatic conversion of Spectrum CSS styles to SWC styles was failing—i.e., these were just bugs. Does that seem right to you?

As a matter of principle, my preference would be to split these fixes out into a separate PR, with a changeset describing the fixes.

graynorton · 2025-10-15T18:39:06Z

first-gen/packages/status-light/src/StatusLight.ts

+    // ───────────────────────
+
+    /**
+     * @todo This property is deprecated in S2, and can be removed once we are no longer maintaining S1.


Yes, I think we should just go ahead and deprecate this, with an appropriate customer-facing message, similar to the ones for the other deprecations in this file.

graynorton · 2025-10-15T18:39:46Z

first-gen/packages/status-light/stories/status-light.stories.ts

 };

 export const s = (): TemplateResult => html`
+    <sp-status-light size="s" variant="accent">accent</sp-status-light>


Yeah—per my earlier comment, I'd prefer that this and the corresponding fixes be pulled out into a separate PR.

graynorton · 2025-10-15T18:42:11Z

first-gen/packages/status-light/test/status-light.test.ts

        expect(el.getAttribute('aria-disabled')).to.equal('true');
    });
+
+    describe('dev mode warnings', () => {


This seems like a good idea to me, but open to dissenting opinions (cc @rubencarvalho).

graynorton · 2025-10-15T19:49:18Z

second-gen/packages/core/components/status-light/StatusLight.base.ts

+            // Check disabled property if it exists (S1 only)
+            if (this.hasAttribute('disabled') && !('disabled' in this)) {
+                window.__swc.warn(
+                    this,
+                    `<${this.localName}> element does not support the disabled state.`,
+                    'https://opensource.adobe.com/spectrum-web-components/components/status-light/#states',
+                    {
+                        issues: [
+                            'disabled is not a supported property in Spectrum 2',
+                        ],
+                    }
+                );
+            } else if (this.hasAttribute('disabled') && 'disabled' in this) {
+                // Set aria-disabled when no warning is shown
+                if (!this.hasAttribute('aria-disabled')) {
+                    this.setAttribute('aria-disabled', 'true');
+                } else {
+                    this.removeAttribute('aria-disabled');
+                }
            }


This case is interestingly different from the similar case in Badge, and I think we should do something slightly different here.

In Badge, we're doing validation of a feature introduced in S2 (outline), which is expected to carry on into the foreseeable future, so it seemed to make sense to put that validation logic in the base class rather than in the 2nd-gen SWC subclass.

In this case, we have two bits of logic related to a feature being removed in S2 (disabled):

Validation to warn when customers try to apply disabled in an S2 context

S1-specific logic for managing state related to the disabled feature

I'd argue that the latter should just live in the S1-specific subclass, where it will eventually fade away into oblivion without further action from us.

The former can stay here, at least for now. @rubencarvalho and I have been discussing the fact that, before going much further, we should decide on an overall philosophy regarding runtime validation of 1st-gen-to-2nd-gen changes (how much of it we want to do, and in what cases).

graynorton · 2025-10-15T20:12:33Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+argTypes.variant = {
+    ...argTypes.variant,
+    name: 'Variant',
+    description:
+        'Changes the color of the status dot. The variant list includes both semantic and non-semantic options.',
+    type: { name: 'string', required: true },
+    table: {
+        type: { summary: 'string' },
+        defaultValue: { summary: 'info' },
+        category: 'Component',
+    },
+    control: { type: 'select' },
+    options: StatusLight.VARIANTS,
+};


Our vision for where this is going is that pretty much everything populating the table will flow from our code (including JSDocs) all the way through to Storybook, with little to no need for manual intervention in the *.stories.ts files.

To the extent that's not happening yet, I'd like to see if we can diagnose and fix issues in our tooling pipeline.

Meanwhile, I'd like to see us take a light touch, making minor tweaks as needed to unblock / ease testing during development, but otherwise not striving to manually fill gaps between what's currently showing and where we'd eventually like to get.

Since we're not expecting customers to be referring to the 2nd-gen Storybook for some time yet, the rough edges shouldn't hurt anyone, and their continued presence should help incentivize us to address the root-cause issues in the tool chain! 😁

If I look at what you've done here and compare it to the equivalent of what's being done in Badge:

argTypes.variant = { ...argTypes.variant, control: { type: 'select' }, options: StatusLight.VARIANTS, };

...they seem essentially equivalent in terms of behavior, and your improvement to the description can be achieved by editing the JSDoc in component implementation, so I'd like to see us fall back to the lighter version. Does that make sense? Let me know if I'm missing anything significant.

(Ultimately, I'm hoping we don't even have to do this much augmentation—I think we should be able to dial in our tooling to the point where it all "just works.")

graynorton · 2025-10-15T20:17:02Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+ * We may have to explicitly bind the args to the component (particularly
+ * helpful for the size property) so the Storybook controls work as expected.
+ * 
+ * i.e. render: (args) =>
+        html`<swc-status-light .size=${args.size} variant=${args.variant}
+            >${args['default-slot']}</swc-status-light
+        >`,


The getStorybookHelpers function is supposed to automatically handle the bindings, but it's not working as expected for certain properties; in the case of size, I think it's probably because properties from mixins are not propagating as they should through the Custom Element Manifest generation process.

I see this falling into the same category I was discussing in my previous comment—our preferred option is to see if we can make our tooling "just work", so we don't have to manually bind templates in our stories. If we try that and fail, then I think we can fall back to something like this.

graynorton · 2025-10-15T22:29:30Z

second-gen/packages/swc/components/status-light/stories/status-light.stories.ts

+    args: {
+        ['default-slot']: 'Status light',
+        variant: 'info',
+        size: 'm',


This is a good question! SizedMixin is not too complex, so the implications of noDefaultSize should be easy enough to reason about. Not having thought through the nuances, and without knowing the history, it's hard to say why SWC would be applying noDefaultSize if the design does, in fact, call for a default size, but I'm hopeful we'll be able to make sense of it.

Meanwhile, I would guess that there's no issue with having a default size from a Storybook perspective, even if there are legitimate technical reasons why noDefaultSize is the right choice from a SizedMixin point of view.

That said, for the sake of consistency in the way we're overriding args in our Barebones stories, I'd prefer that we insert these lines above the declaration of meta:

args['default-slot'] = 'Status light'; args.size = 'm';

...and then just refer to args in the meta declaration, rather than define it inline, e.g.:

const meta: Meta = { /* other props... */ args, };

graynorton · 2025-10-15T22:34:22Z

second-gen/packages/swc/components/status-light/test/status-light.test.ts

Technically speaking, tests weren't required for these Barebones component migrations.

I am neutral on whether we take these as part of this PR or pull them out and consider testing more holistically across the Barebones components.

@rubencarvalho, thoughts?

marissahuysentruyt self-assigned this Oct 10, 2025

marissahuysentruyt added WIP Component: Status Light S2 2nd gen These issues or PRs map to our 2nd generation work to modernizing infrastructure. Spectrum CSS Spectrum 2 Issues related to Spectrum 2 labels Oct 10, 2025

marissahuysentruyt added 2 commits October 13, 2025 11:07

feat(statuslight): create shared types file

b5ff0dd

feat(status-light): import types into core status-light

14f1ddb

marissahuysentruyt force-pushed the marissahuysentruyt/swc-1260-status-light-s2-migration branch from 778adb4 to faba5c8 Compare October 13, 2025 15:10

marissahuysentruyt force-pushed the marissahuysentruyt/swc-1260-status-light-s2-migration branch from faba5c8 to f32d35c Compare October 13, 2025 16:45

marissahuysentruyt added 3 commits October 13, 2025 14:12

refactor(status-light): status light second-gen

c53108e

- imports new S2 types for colors and semantic variants - adds the api overrides - adds documentation and example usage - refactors template render to use CSS classes and classMap()

refactor(status-light): status light first-gen

7552d10

- imports new S1 types for colors and semantic variants - adds the api overrides and extra disabled property - adds documentation, deprecation notices, and example usage

feat(status-light): add s2 styles

2f767ea

marissahuysentruyt force-pushed the marissahuysentruyt/swc-1260-status-light-s2-migration branch from f32d35c to a22afc0 Compare October 13, 2025 18:14

marissahuysentruyt changed the title ~~Marissahuysentruyt/swc 1260 status light s2 migration~~ feat(status-light)!: migrate status-light to s2 styles and second-gen architecture Oct 13, 2025

marissahuysentruyt added 6 commits October 14, 2025 15:35

feat(status-light): add second-gen stories

78386c5

feat(statuslight): add sizeMap decorator

f3ec69c

refactor(statuslight): correct accent and cyan variant selectors

ef3c4a1

feat(statuslight): add missing first-gen variants to stories

b72ca8d

test(status-light): add dev mode warning tests in first-gen

1dd69f0

test(statuslight): add second-gen test file

888651e

marissahuysentruyt force-pushed the marissahuysentruyt/swc-1260-status-light-s2-migration branch from a22afc0 to 888651e Compare October 14, 2025 19:36

marissahuysentruyt commented Oct 14, 2025

View reviewed changes

marissahuysentruyt marked this pull request as ready for review October 14, 2025 19:56

marissahuysentruyt requested a review from a team as a code owner October 14, 2025 19:56

adobe deleted a comment from cursor bot Oct 14, 2025

marissahuysentruyt added the ready-for-review label Oct 14, 2025

marissahuysentruyt commented Oct 14, 2025

View reviewed changes

marissahuysentruyt requested review from Rajdeepc, TarunAdobe, castastrophe, cdransf, graynorton and rubencarvalho October 15, 2025 12:51

castastrophe approved these changes Oct 15, 2025

View reviewed changes

graynorton requested changes Oct 15, 2025

View reviewed changes

feat(status-light)!: migrate status-light to s2 styles and second-gen architecture #5800

Are you sure you want to change the base?

feat(status-light)!: migrate status-light to s2 styles and second-gen architecture #5800

Conversation

marissahuysentruyt commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Key changes

Motivation and context

Related issue(s)

Screenshots (if appropriate)

Author's checklist

Reviewer's checklist

Manual review test cases

First-gen status-light functionality

Second-gen status-light functionality

Shared base class validation

Device review

Uh oh!

changeset-bot bot commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

github-actions bot commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Branch Preview

🔍 Visual Regression Test Results

Uh oh!

github-actions bot commented Oct 13, 2025

Tachometer results

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marissahuysentruyt Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marissahuysentruyt Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

castastrophe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marissahuysentruyt commented Oct 10, 2025 •

edited

Loading

changeset-bot bot commented Oct 10, 2025 •

edited

Loading

github-actions bot commented Oct 13, 2025 •

edited

Loading

marissahuysentruyt Oct 14, 2025 •

edited

Loading

marissahuysentruyt Oct 14, 2025 •

edited

Loading