Skip to content

chore(deps-dev): bump @tenphi/eslint-plugin-tasty from 0.11.3 to 1.0.0 - #260

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/tenphi/eslint-plugin-tasty-1.0.0
Open

chore(deps-dev): bump @tenphi/eslint-plugin-tasty from 0.11.3 to 1.0.0#260
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/tenphi/eslint-plugin-tasty-1.0.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 13, 2026

Copy link
Copy Markdown
Contributor

Bumps @tenphi/eslint-plugin-tasty from 0.11.3 to 1.0.0.

Release notes

Sourced from @​tenphi/eslint-plugin-tasty's releases.

v1.0.0

Major Changes

  • #38 60dbc05 Thanks @​tenphi! - ## Target @tenphi/tasty v3

    The plugin now validates the v3 style DSL. Most of the upgrade is mechanical: the renamed at-rule keys are reported with an auto-fix, so eslint --fix handles them.

    For tasty v2, pin @tenphi/eslint-plugin-tasty@^0.11. @tenphi/tasty >=3 is declared as an optional peer dependency so a v2 pairing is flagged by the package manager rather than surfacing as spurious at-rule rename errors. It stays optional because the plugin has no runtime dependency on tasty — it validates source text.

    $$name(...) CSS function calls no longer error

    v3 adds CSS @function support, invoked as $$name(...). Because bare $$name is the custom-property reference transition uses, the classifier's $$ branch ran first and rejected the call form outright — padding: '$$negative(10px)' produced a hard valid-value error, and valid-custom-property demanded that $negative be declared as a token.

    Calls are now recognized as a distinct tasty-function token before the bare-reference check, and the valid-custom-property / valid-color-token regexes no longer match a name followed by (. The bare $$name / ##name forms are unchanged, so transition: '$$gradient-angle 0.3s' still validates. A malformed name ($$9bad(10px)) still reports.

    At-rule keys use the CSS at-rule spelling

    v3 renamed the camelCase keys to match the at-rules Tasty already emitted. valid-styles-structure reports the old spellings with a fix:

    '@properties'   ->  '@property'
    '@fontFace'     ->  '@font-face'
    '@counterStyle' ->  '@counter-style'
    

    @function is recognized as a special key and its value is structure-checked. Previously every @-prefixed key was accepted unconditionally, so v3 code got no validation at all and v2 code got no migration signal.

    The at-rule list is now also used consistently: isStateMap excludes all five at-rule keys (it previously excluded only @keyframes and @properties, so a @font-face or @counter-style descriptor map could be mistaken for a state map), and valid-value skips all of them.

    One value per directional group

    v3 dropped the positional multi-value form. Values and modifiers are bucketed separately per comma group, so '2x 4x top right', '2x top 4x right', and 'top 2x right 4x' were the same input and the pairing depended on which order the modifiers happened to appear in. valid-directional-modifier now reports a group that names directions and carries more than one value:

    padding: '2x 4x top right'   ->  padding: '2x top, 4x right'
    fade:    '3x 1x top bottom'  ->  fade:    '3x top, 1x bottom'
    

    Applies to padding, margin, inset, scrollMargin, and fade. Not to border (a group carries width + style + color) or radius (leaf/backleaf take two values) — neither uses the positional per-side form. Groups that name no direction keep plain CSS shorthand order, so padding: '1x 2x 3x 4x' and fade: '3x 1x' are still valid, as is a CSS-wide keyword alongside a direction (padding: 'inherit top'). inset's dock keeps its two-value form; a third value reports.

    The rule now parses with the shared value parser instead of splitting on whitespace, which is what makes comma groups visible to it.

    valid-directional-modifier message and scope

    A direction outside a property's own set (padding: '1x top-left') now reports with the accepted list rather than the misleading "does not support directional modifiers", and the rule no longer descends into $ affix values (a selector, not a value — $: '.active' was read as an unknown unit), sub-element keys, or at-rule blocks.

    The rule still skips properties with no directional vocabulary, which makes the "wrong property" case (fill: '#purple top') unreachable. That gate looks like a bug but is load-bearing: direction words are ordinary CSS values for a long tail of properties — verticalAlign: 'bottom', textAlign: 'left', transformOrigin: 'top center', backgroundPosition, objectPosition, float, clear, scrollSnapAlign, and transition, whose value names properties that can themselves be left/top. Removing it reported 20 errors across @cube-dev/ui-kit, every one a false positive. Catching a stray fill: '#purple top' is not worth an allowlist of every property that takes a positional keyword. All 20 cases are now regression tests.

    scrollMargin accepts directional modifiers

... (truncated)

Changelog

Sourced from @​tenphi/eslint-plugin-tasty's changelog.

1.0.0

Major Changes

  • #38 60dbc05 Thanks @​tenphi! - ## Target @tenphi/tasty v3

    The plugin now validates the v3 style DSL. Most of the upgrade is mechanical: the renamed at-rule keys are reported with an auto-fix, so eslint --fix handles them.

    For tasty v2, pin @tenphi/eslint-plugin-tasty@^0.11. @tenphi/tasty >=3 is declared as an optional peer dependency so a v2 pairing is flagged by the package manager rather than surfacing as spurious at-rule rename errors. It stays optional because the plugin has no runtime dependency on tasty — it validates source text.

    $$name(...) CSS function calls no longer error

    v3 adds CSS @function support, invoked as $$name(...). Because bare $$name is the custom-property reference transition uses, the classifier's $$ branch ran first and rejected the call form outright — padding: '$$negative(10px)' produced a hard valid-value error, and valid-custom-property demanded that $negative be declared as a token.

    Calls are now recognized as a distinct tasty-function token before the bare-reference check, and the valid-custom-property / valid-color-token regexes no longer match a name followed by (. The bare $$name / ##name forms are unchanged, so transition: '$$gradient-angle 0.3s' still validates. A malformed name ($$9bad(10px)) still reports.

    At-rule keys use the CSS at-rule spelling

    v3 renamed the camelCase keys to match the at-rules Tasty already emitted. valid-styles-structure reports the old spellings with a fix:

    '@properties'   ->  '@property'
    '@fontFace'     ->  '@font-face'
    '@counterStyle' ->  '@counter-style'
    

    @function is recognized as a special key and its value is structure-checked. Previously every @-prefixed key was accepted unconditionally, so v3 code got no validation at all and v2 code got no migration signal.

    The at-rule list is now also used consistently: isStateMap excludes all five at-rule keys (it previously excluded only @keyframes and @properties, so a @font-face or @counter-style descriptor map could be mistaken for a state map), and valid-value skips all of them.

    One value per directional group

    v3 dropped the positional multi-value form. Values and modifiers are bucketed separately per comma group, so '2x 4x top right', '2x top 4x right', and 'top 2x right 4x' were the same input and the pairing depended on which order the modifiers happened to appear in. valid-directional-modifier now reports a group that names directions and carries more than one value:

    padding: '2x 4x top right'   ->  padding: '2x top, 4x right'
    fade:    '3x 1x top bottom'  ->  fade:    '3x top, 1x bottom'
    

    Applies to padding, margin, inset, scrollMargin, and fade. Not to border (a group carries width + style + color) or radius (leaf/backleaf take two values) — neither uses the positional per-side form. Groups that name no direction keep plain CSS shorthand order, so padding: '1x 2x 3x 4x' and fade: '3x 1x' are still valid, as is a CSS-wide keyword alongside a direction (padding: 'inherit top'). inset's dock keeps its two-value form; a third value reports.

    The rule now parses with the shared value parser instead of splitting on whitespace, which is what makes comma groups visible to it.

    valid-directional-modifier message and scope

    A direction outside a property's own set (padding: '1x top-left') now reports with the accepted list rather than the misleading "does not support directional modifiers", and the rule no longer descends into $ affix values (a selector, not a value — $: '.active' was read as an unknown unit), sub-element keys, or at-rule blocks.

    The rule still skips properties with no directional vocabulary, which makes the "wrong property" case (fill: '#purple top') unreachable. That gate looks like a bug but is load-bearing: direction words are ordinary CSS values for a long tail of properties — verticalAlign: 'bottom', textAlign: 'left', transformOrigin: 'top center', backgroundPosition, objectPosition, float, clear, scrollSnapAlign, and transition, whose value names properties that can themselves be left/top. Removing it reported 20 errors across @cube-dev/ui-kit, every one a false positive. Catching a stray fill: '#purple top' is not worth an allowlist of every property that takes a positional keyword. All 20 cases are now regression tests.

    scrollMargin accepts directional modifiers

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [@tenphi/eslint-plugin-tasty](https://github.com/tenphi/eslint-plugin-tasty) from 0.11.3 to 1.0.0.
- [Release notes](https://github.com/tenphi/eslint-plugin-tasty/releases)
- [Changelog](https://github.com/tenphi/eslint-plugin-tasty/blob/main/CHANGELOG.md)
- [Commits](tenphi/eslint-plugin-tasty@v0.11.3...v1.0.0)

---
updated-dependencies:
- dependency-name: "@tenphi/eslint-plugin-tasty"
  dependency-version: 1.0.0
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added the dependencies Pull requests that update a dependency label Aug 13, 2026
@dependabot
dependabot Bot deployed to release August 13, 2026 05:44 Active
@github-actions

Copy link
Copy Markdown
Contributor

📦 Snapshot release

Published 0.0.0-snapshot.dffd134.

pnpm add @tenphi/tasty@0.0.0-snapshot.dffd134

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

Labels

dependencies Pull requests that update a dependency

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants