Skip to content

Warn on base typography token usage#677

Open
lukasoppermann wants to merge 1 commit intomainfrom
warn-base-tokens
Open

Warn on base typography token usage#677
lukasoppermann wants to merge 1 commit intomainfrom
warn-base-tokens

Conversation

@lukasoppermann
Copy link
Copy Markdown
Contributor

Motivation

Base typography tokens (--base-text-weight-*, --base-text-size-*, --base-text-lineHeight-*) are lower-level primitives. Users should prefer functional tokens (e.g. --text-title-weight-medium) for better semantic meaning and maintainability. Currently, base tokens are silently accepted — this PR surfaces a warning to nudge users toward functional alternatives without blocking their workflow.

Approach

The primer/typography plugin now detects var(--base-*) values and reports them with severity: 'warning'. This means:

  • Functional tokens (e.g. --text-title-size-medium) → accepted silently ✅
  • Base tokens (e.g. --base-text-weight-semibold) → warning ⚠️ (informational, won't fail CI)
  • Hardcoded values (e.g. font-weight: 500) → error ❌ (unchanged)

When auto-fix replaces a hardcoded value with a base token (e.g. 500var(--base-text-weight-medium)), the base token warning is also emitted so the user is aware the replacement is a base-level token.

Changes

  • plugins/typography.js — Added baseToken message, base token detection after variable validation, and post-fix warning emission
  • __tests__/typography.js — Moved base token case from accept to reject with warning, added test cases for base font-size and line-height

Created with GitHub Desktop

Add a warning (severity: 'warning') when users use base tokens like
--base-text-weight-*, --base-text-size-*, or --base-text-lineHeight-*
instead of functional typography tokens. The warning informs users but
does not block CI or cause lint errors.

Also emits the base token warning after auto-fix replaces a hardcoded
value with a base token, so users are aware of the recommendation.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings March 9, 2026 15:55
@lukasoppermann lukasoppermann requested a review from a team as a code owner March 9, 2026 15:55
@lukasoppermann lukasoppermann requested a review from jonrohan March 9, 2026 15:55
@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Mar 9, 2026

⚠️ No Changeset found

Latest commit: 43e8374

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

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds a warning-severity lint message for base typography token usage (e.g., --base-text-weight-*, --base-text-size-*, --base-text-lineHeight-*) in the primer/typography Stylelint plugin. Users are nudged toward functional tokens for better semantic meaning, while hardcoded values remain errors and base tokens become warnings that won't block CI.

Changes:

  • Added a baseToken warning message and base token detection logic in the typography plugin so that var(--base-*) typography tokens are reported as warnings rather than silently accepted.
  • Implemented post-fix warning emission so that when auto-fix replaces a hardcoded value with a base token, an additional baseToken warning is emitted.
  • Updated test cases to move base token usage from accept to reject (with warning) and added test cases for base font-size and line-height.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File Description
plugins/typography.js Added baseToken message, base token regex detection after variable validation, and post-fix warning emission for auto-fixed base tokens
__tests__/typography.js Moved base font-weight token from accept to reject with warning assertion; added new reject cases for base font-size and line-height tokens

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +124 to +134
if (/var\(--base-/.test(value)) {
report({
index: declarationValueIndex(declNode),
endIndex: declarationValueIndex(declNode) + value.length,
message: messages.baseToken(value),
node: declNode,
result,
ruleName,
severity: 'warning',
})
}
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The __tests__/__fixtures__/good/ fixture files still contain base typography tokens that will now trigger warnings:

  • example.pcss:19font-weight: var(--base-text-weight-medium)
  • example.scss:19font-weight: var(--base-text-weight-semibold)
  • example.scss:23font-weight: var(--base-text-weight-normal)

While warnings won't cause npm run test:stylelint to exit with a non-zero code, the "good" fixtures are conceptually the reference for clean/passing code. These files should be updated to use functional tokens (e.g., --text-title-weight-medium) or have /* stylelint-disable primer/typography */ comments to suppress the warning, keeping the fixtures truly warning-free.

Copilot uses AI. Check for mistakes.

if (checkForVariable(validValues, value)) {
// Warn when using base tokens (e.g. --base-text-weight-*) instead of functional tokens
if (/var\(--base-/.test(value)) {
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The regex /var\(--base-/ doesn't account for optional whitespace inside var(). While uncommon, a declaration like font-weight: var( --base-text-weight-semibold ) would pass checkForVariable (matching the variable name) but not trigger the warning (the regex expects var(--base- with no space). Consider using a more lenient pattern such as /var\(\s*--base-/ for robustness.

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this would make the code stronger, I think we have formatting rules that wouldn't allow you to include whitespace inside the var declaration. I'm fine shipping as is

Comment on lines +182 to +193
if (didFix && isBaseTokenFix) {
const newValue = declNode.value
report({
index: declarationValueIndex(declNode),
endIndex: declarationValueIndex(declNode) + newValue.length,
message: messages.baseToken(newValue),
node: declNode,
result,
ruleName,
severity: 'warning',
})
}
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The didFix && isBaseTokenFix code path (lines 182–193) only fires in Stylelint's fix mode, and none of the test cases verify that the baseToken warning is actually emitted after a fix. The existing fixable test cases (e.g., font-weight: 500) only assert the rejected message, which is evaluated in non-fix mode. Consider adding a test that validates the baseToken warning is emitted post-fix — for instance, by using warnings (plural) with two entries for a fixable case, or by adding a dedicated test that runs in fix mode and checks for the warning on the fixed output.

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Member

@jonrohan jonrohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea! 👍🏻


if (checkForVariable(validValues, value)) {
// Warn when using base tokens (e.g. --base-text-weight-*) instead of functional tokens
if (/var\(--base-/.test(value)) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this would make the code stronger, I think we have formatting rules that wouldn't allow you to include whitespace inside the var declaration. I'm fine shipping as is

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants