SWAN's ESLint package is a custom linting plugin designed to enforce the Vista Design System's evolving design language across JavaScript and TypeScript files. It helps developers write consistent and accessible SWAN-specific code by identifying deviations from SWAN’s design principles and coding conventions, thereby reducing variations.
Getting started
Prerequisites
- An ESLint setup in your project
- Peer dependencies
@vp/swan
>= 3.18.1 < 4@typescript-eslint/parser
^7 || ^8eslint
^8.45.0 || ^9typescript
>= 4.8.4
- Node.js >= 18.18.0
Installation
Usage
You can integrate the plugin into your project by adding it to your ESLint config file.
Flat ESLint Config (>= ESLint v9)
Legacy ESLint Config (< ESLint v9)
Setting individual rules
To best align with SWAN's best practices, it's advised to use the recommended configuration (shown above). However, it's possible to enable, disable, or alter the severity of individual rules if required.
Flat ESLint Config (>= ESLint v9)
Legacy ESLint Config (< ESLint v9)
TypeScript Projects: Type-Aware Rule Setup
Some rules in this plugin (like @vp/swan/no-deprecated
) use TypeScript's type information to provide more accurate linting. These "type-aware" rules require special configuration to work properly.
When You Need This Setup
When your main tsconfig.json
only covers certain directories (like src/
), but ESLint needs to lint files outside those folders—such as tests, configuration files, or scripts. You may also need this setup if you encounter errors about missing type information during linting. Refer to the Typed Linting FAQ.
How to Configure
To enable type-aware linting, create a dedicated `tsconfig.eslint.json` at your project root. This ensures ESLint can access type information for all relevant files, including tests and config scripts.
1. Create tsconfig.eslint.json
:
2. Update your Flat ESLint Config:
Add the parserOptions.project
field to point to your config:
3. Update your Legacy ESLint Config (`.eslintrc`):
Set the parserOptions.project
field:
Rules included
Each rule has its own README with usage, rationale, and examples.
Rule ID | Description | Default Severity | Docs with examples | Suggestion available |
---|---|---|---|---|
@vp/swan/enforce-font-skin Introduced in v1.0 | Using individual font styling props (fontSize , fontWeight , fontFamily ) can lead to inconsistent typography that doesn't align with the design system. The recommended path for setting typography is the fontSkin prop, which bundles together all typography related styling decisions. Don't use other explicit typographic props. | warn | README | Partially |
@vp/swan/enforce-grid-structure Introduced in v1.0 | This rule ensures that grid layout components are nested in a valid hierarchy: GridContainer > Row > Column each immediate child of it's previous or a React fragment. | error | README | - |
@vp/swan/no-classnames Introduced in v1.0 | Disallow the use of SWAN classes. Manually applying SWAN classes such as swan-* class whether on any element or components, can make the UI fragile and inconsistent, since SWAN may update or remove these class names at any time | error | README | - |
@vp/swan/no-deprecated Introduced in v1.0 | Flags all deprecated SWAN symbols (components, props, functions, etc) which should be avoided where possible as they will be removed in a future version of SWAN. If a replacement is recommended, that should be used instead, otherwise remove usage of the symbol. | error | README | Partially |
@vp/swan/no-deprecated-tokens Introduced in v1.0 | Deprecated SWAN tokens should be avoided where possible as they will be removed in a future version of SWAN. If a replacement is recommended, developers should use that instead otherwise should remove usage of the token. | error | README | Partially |
@vp/swan/no-internal-components Introduced in v1.0 | This rule ensures that developers do not use internal-only components from the @vp/swan package. These components are not part of the public API and may change without notice. Includes components like Dialog , PopoverTrigger and all BaseTile related | error | README | No |
@vp/swan/no-internal-tokens Introduced in v1.0 | Disallows use of internal SWAN tokens like SwanInternal* , SwanComp* which are not part of the public or semantic API and may change without notice. Developers should rely on semantic (SwanSem* ) tokens. If no suitable semantic token exists for the use case, use a base token or reach out to the design system team before considering alternatives. | error | README | No |
@vp/swan/no-mixed-font-props Introduced in v1.0 | The fontSkin prop is designed to encapsulate all typographic styling decisions. Using it alongside individual font-related props (fontSize , fontWeight , or fontFamily ) introduces ambiguity and breaks design consistency. This rule ensures that once fontSkin is used, all other individual font props are flagged. | error | README | - |
@vp/swan/required-accessibility-props Introduced in v1.0 | This rule helps developers add appropriate accessibility-related props to respective SWAN components. These props were introduced as optional to avoid breaking changes, but will be made required in the next major SWAN update. | error | README | Yes |
Troubleshooting/FAQs
See above section TypeScript Projects: Type-Aware Rule Setup
Update your ESLint version to 8.45 or above.
If your SWAN rule config changes (like severity overrides) aren’t showing up right away in your IDE, try restarting the ESLint server or just reload the IDE.
We understand that setting up type-aware linting can be challenging (especially in monorepos with complex tsconfig setups).
We've documented a general solution in the above sectionTypeScript Projects: Type-Aware Rule Setup that can be adapted to most setups. However, consumers may need to explore and adjust the configuration based on their specific project structure.
If the documented solution doesn't work for you, feel free to reach out to the #help-swan channel. We're happy to take a quick look—if the fix looks straightforward, we’ll guide you through it.
Changelog
See the complete Changelog