refactor: [M3-9591] - Cleanup token organization and paths

[abailly-akamai]

Description 📝

This PR refactors our tokens so they are better organized and easier to use. It reduces our access to tokens through these 5 categories (for now!) and exposes all component tokes to the application.

tokens: {
  alias: Alias, // ex: theme.tokens.alias.Action.Negative.Default
  color: Color, // ex: theme.tokens.color.Green[70]
  component: Component, // ex: theme.tokens.component.Dropdown.Text.Default
  font: Font, // ex: theme.tokens.font.FontSize.Xxxs
  spacing: Spacing, // ex: theme.tokens.spacing.S8
}

The main goal is facilitates token discovery for DX. A better categorization streamlines IDE suggestions and help cognitive token discovery while developing.

Changes 🔄

• Flatten token categories and separate concern between primary token concepts.
• Update token name chaining through application

Preview 📷

This PR is targeting naming conventions & DX. There should be no functional or visual regressions

How to test 🧪

Verification steps

• Confirm CI is passing
• Confirm no visual regression in application

Author Checklists

As an Author, to speed up the review process, I considered 🤔

👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support

• I have read and considered all applicable items listed above.

As an Author, before moving this PR from Draft to Open, I confirmed ✅

• All unit tests are passing
• TypeScript compilation succeeded without errors
• Code passes all linting rules

[github-actions]

Coverage Report: ✅
Base Coverage: 79.96%
Current Coverage: 79.96%

[jaalah-akamai]

Thanks for recommending these, I think this will bring clarity around the tokens as well as simplicity.

[jaalah-akamai]

I actually forget why these are needed here apart from the base light.ts file?

[abailly-akamai]

this looks very much like a @bnussman-akamai thing -

// This is a hack to create breakpoints outside of the theme itself.
// This will likely have to change at some point 😖

it's unclear from the comment what the purpose is

[abailly-akamai]

I removed the token declarations from here , assuming they are not needed. Maybe Banks can chime in on this

[bnussman-akamai]

If I remember correctly, @mui/material removed (or doesn't have?) the ability to create breakpoints outside of the theme, which we rely on somewhat heavily in light.ts and dark.ts so I had to use createTheme as a hack here to generate the breakpoints.

light.ts and dark.ts import breakpoints and use it construct the theme.

Look at this diff for context: https://github.com/linode/manager/pull/11081/files#diff-273e3bd36fcb185d72c1982521d282dd0ea1d90bcc453b1706125a18438aa70e

---

Ideally, we'd define the breakpoint inside of lights.ts and reference breakpoints by using a function within the theme

MuiTab: {
  styleOverrides: {
    root: ({ theme }) => ({
      [theme.breakpoints.up('md')]: {
        minWidth: 75,
      },
    }),
  },
},

rather than what we do, which is:

MuiTab: {
  styleOverrides: {
    root: {
      [breakpoints.up('md')]: {
        minWidth: 75,
      },
    },
  },
}

but we can't use the function notation in our theme because MUI's deepmerge does not support the function syntax, which is what we use to merge our light and dark theme to create the dark theme. I tried this and it caused dark mode regressions.

In summary:

We must define our breakpoint values outside of the theme. If we try to define breakpoint values directly in the theme and reference them with the ({ theme }) => ({}) syntax, dark mode regressions occur because our theme merging does not support it. I had to use a hack to allow us to create breakpoints outside of the theme

---

Looking at this code now, maybe we can use the (new?) unstable_createBreakpoints to get things back in a sane state?

This is what I meant by "This will likely have to change at some point 😖 "

This file would become:

import { unstable_createBreakpoints } from '@mui/material';

export const breakpoints = unstable_createBreakpoints({
  values: {
    lg: 1280,
    md: 960,
    sm: 600,
    xl: 1920,
    xs: 0,
  },
});

[abailly-akamai]

Thanks a lot for this explanation @bnussman-akamai - this makes a lot more sense now. I will create a separate ticket to address this as I want to keep the scope reasonable for testing the refactor from this PR

[jaalah-akamai]

✅ Pulled this down and tokens are working as expected.
✅ Light & Dark themes are looking good

[linode-gh-bot]

Cloud Manager UI test results

🔺 1 failing test on test run #6 ↗︎

❌ Failing	✅ Passing	↪️ Skipped	🕐 Duration
1 Failing	538 Passing	3 Skipped	117m 32s

Details

Failing Tests
	Spec	Test
❌	migrate-linode-with-firewall.spec.ts	Migrate Linode With Firewall » migrates linode with firewall - real data

Troubleshooting

Use this command to re-run the failing tests:

pnpm cy:run -s "cypress/e2e/core/firewalls/migrate-linode-with-firewall.spec.ts"

[abailly-akamai]

I changed this btw since semanticTokens is not a thing

[abailly-akamai]

So in the end I'm hoping this won't have negative consequences

[bnussman-akamai]

should be fine ✔️