@luxfi/eslint-config

Shared ESLint configuration for Lux projects, plus a set of custom lint rules.

This package was extracted from the luxfi/exchange monorepo into a standalone package.

Install

pnpm add -D @luxfi/eslint-config [email protected]

Usage

Extend the appropriate config in your .eslintrc:

{
  "extends": ["@luxfi/eslint-config/base"]
}

Available configs

Entry	Purpose
base.js	Base config for TypeScript projects (package main)
native.js	React Native config
lib.js	Library config
load.js	Loader helper
biome-supported.js	Subset of rules also supported by Biome
restrictedImports.js	Shared restricted-imports policy

Custom rules live in plugins/, with shared helpers in utils/.

Custom Rules

Prelude

In most cases, a core or community rule will suffice for your use case, as these rules tend to be robust and performant; use a custom rule when these rules cover too little for your specific use case (ie not robust/applicable) or too much (ie not performant).

Steps

1. Ensure there is no available rule that sufficiently covers your use case
2. Create two files in plugins/: <your-lint-name>.js and <your-lint-name>.test.js
   • align naming with ESLint core naming conventions
3. Create your lint rule using steps 2-4 here
   • it's much easier to find the node names (eg, JSXText, JSXExpressionContainer) for the visitor methods using this explorer
4. Add tests
5. Import new rule to universe/eslint-local-rules
6. Add your shiny new rule to native.js, base.js, and – if it's a react lint rule - react.js
7. Test, test, test; cover all your bases
   • remember that this rule will checked against nearly every single LOC in the codebase
8. Profile with TIMING=1 bun g:lint and ensure your rule is performant
   • rules should generally not exceed 25 ms (~1%) for each package

Tips and resources

• For configurable lists (eg greenlisted elements), lean towards passing a variable as a rule config rather than using a const, so as to avoid having to update the rule itself as the codebase evolves
• Avoid traversing children in a custom rule to avoid performance issues. Ideally, you target the nodes directly
• As with any lint rule, make sure the tradeoff in DevX (eg slower lint times, more styling considerations) is worth the benefits
• Utilize the ESLint docs