Skip to content

Add no-inline-styles lint rule#28

Open
danielchen0 wants to merge 1 commit intomainfrom
add-no-inline-styles-rule-v2
Open

Add no-inline-styles lint rule#28
danielchen0 wants to merge 1 commit intomainfrom
add-no-inline-styles-rule-v2

Conversation

@danielchen0
Copy link
Collaborator

Summary

  • Adds no-inline-styles rule that flags style={{...}} JSX attributes and suggests using Tailwind CSS classes instead
  • Allows style props with variable references (e.g., style={dynamicStyle})

Test plan

  • All existing tests pass
  • 6 new tests pass
  • TypeScript compiles
  • Prettier passes

Copy link
Contributor

@arnavsurve arnavsurve left a comment

Choose a reason for hiding this comment

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

This is a clean, well-structured PR that follows the existing codebase conventions closely. The rule implementation is correct, the tests are thorough, and the documentation is properly updated.

What looks good:

  • The AST traversal logic correctly identifies style={{...}} (inline object expressions) while allowing style={variable} references, which is the right behavior.
  • Test coverage is solid: positive cases (single element, different elements, multiple violations), negative cases (className, variable reference, no style prop).
  • README table, rule detail section, rule count bump, and test count bump are all updated consistently.
  • Code style matches existing rules (e.g., no-tailwind-animation-classes) perfectly.

Minor observations (non-blocking):

  • The no-stylesheet-create rule's message says "Use inline styles instead of StyleSheet.create()", while this new rule says "Avoid inline styles. Use Tailwind CSS classes instead." Together they form a logical migration path (StyleSheet.create -> inline -> Tailwind), but the no-stylesheet-create message could be slightly confusing if both rules fire in the same codebase. This is pre-existing and outside the scope of this PR.
  • The rule will not flag style={(() => ({ color: 'red' }))()} (IIFE returning an object) or style={{...someSpread}} (spread inside object literal -- this one actually would be caught since it's still an ObjectExpression). These edge cases are reasonable to not worry about since the common pattern is what matters.
  • The README intro section still says "all 31 rules" in the config section, but the Available Rules heading correctly says 34. This is also pre-existing.

LGTM!

🤖 Generated with Claude Code

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.

2 participants