AbsoluteJS
AbsoluteJS

ESLint

ESLint rules for AbsoluteJS applications. Identify and fix problems in your code with static analysis that enforces coding standards and best practices.

View on GitHub
#

absolute/explicit-object-types

Requires objects to have explicit TypeScript type annotations instead of relying on implicit inference. This is meant for stricter definitions of objects so the type can be reused. Note that `as const` is allowed here because it gives the object a constant shape.

TS
1export const defaultConfig = {
2maxUsers: 10,
3name: "app"
4};
#

absolute/localize-react-props

This rule encourages keeping component logic and data as close to where they're used as possible. If a variable is only used as a prop for a single component, it should be defined inside that component rather than being passed down as a prop.

TS
1const x = 5;
2
3<MyComponent value={x} />;
#

absolute/max-depth-extended

This is the exact same rule as max-depth from ESLint except it allows you to break the max-depth if you exit early via a return or throw statement.

TS
1if (a) {
2    if (b) {
3        doThing();
4    }
5}
#

absolute/max-jsxnesting

Limits JSX nesting depth to improve readability and maintainability. Deeply nested markup should be broken into smaller components.

TS
1const MyComponent = () => (
2	<div>
3		<section>
4			<article>
5				<div>
6					<span>
7						<strong>Deep text</strong>
8					</span>
9				</div>
10			</article>
11		</section>
12	</div>
13);
#

absolute/min-var-length

Enforces a minimum variable name length, like default: 3. Improves readability and discourages overly short variable names.

TS
1const x = fetchData();
#

absolute/no-button-navigation

This rule prevents using button clicks, or other UI event handlers, to directly manipulate the browser's navigator object. In other words, you shouldn't perform navigation actions like window.location, navigator.pushState, or similar operations inside button event handlers.

TS
1<button onClick={() => (window.location.href = '/home')}>
2    Go Home
3</button>
#

absolute/no-explicit-return-type

This rule disallows adding explicit return type annotations to functions when TypeScript can already infer the type automatically. TypeScript's type inference system is highly accurate and adapts as your code changes — meaning that explicitly declaring return types in these cases can make your code more rigid and harder to maintain.

TS
1const getUserName = (user: User): string => {
2    return user.name;
3}
#

absolute/no-inline-prop-types

Enforces the use of named or predefined types for component props, preventing the use of inline type definitions when passing props.

TS
1type Props = {
2  style: { marginTop: number };
3};
4
5const MyComp = ({ style }: Props) => <div style={style} />;
#

absolute/no-multi-style-objects

Ensures style objects are centralized and reused rather than scattered across the component. Improves maintainability and performance.

TS
1const styles = {
2  redBox: { color: 'red', padding: 4 },
3  blueBox: { color: 'blue', margin: 8 },
4  greenBox: { color: 'green', border: '1px solid' },
5};
6
7<div style={styles.redBox} />
8<div style={styles.blueBox} />
9<div style={styles.greenBox} />
#

absolute/no-nested-jsx-return

Prevents nested JSX return statements, which can make code less readable and harder to maintain.

TS
1const items = ['apple', 'banana', 'cherry'];
2
3const List = () => (
4  <div>
5    {items.map((item) => (
6      <div>
7        <h3>{item}</h3>
8        <p>Delicious fruit</p>
9      </div>
10    ))}
11  </div>
12);
#

absolute/no-or-none-component

Prevents components that inconsistently return different types, like a component or null. Encourages conditional rendering instead of “Maybe” component patterns.

TS
1const MaybeButton({ enabled }) {
2	if (enabled) return <Button />;
3	return null;
4}
#

absolute/no-transition-cssproperties

This rule prevents using the transition CSS property completely. Using CSS transitions can interfere with React Spring's animation system, causing unexpected or broken animations. All animations and transitions should be handled through React Spring instead of native CSS transitions.

TS
1<div style={{ transition: 'all 0.3s ease' }} />
#

absolute/no-unnecessary-div

This rule removes unnecessary wrapper &lt;div&gt; elements that don't provide meaningful structure or purpose. If a wrapper is only used for styling, that styling should be moved into the child component instead.

TS
1<div>
2    <span>Text</span>
3</div>
#

absolute/no-unnecessary-key

Disallows keys where not needed or inappropriate, like static elements. Encourages correct key usage in dynamic lists.

TS
1<div key="static">Hello</div>
#

absolute/no-useless-function

Prevents trivial wrapper functions that simply call another function without adding logic. Encourages using direct references instead.

TS
1function callFoo(...args) {
2    return foo(...args);
3}
#

absolute/seperate-style-files

Requires that style definitions be located in separate files, like .styles.ts or .css. This keeps component logic and styling concerns separated.

TS
1// Comp.tsx
2const styles = {
3  big: { fontSize: 20 },
4};
5
6export default function Comp() {
7  return <div style={styles.big}>x</div>;
8}
#

absolute/sort-exports

Enforces alphabetical sorting of exports. Variables are listed before functions for clarity and consistency.

TS
1export function b() {}
2export const a = 1;
#

absolute/sort-keys-fixable

This is just the same as the sort-keys ESLint rule with an addition. While it does enforce consistent key ordering within objects it also provides automatic fixing to sort keys alphabetically, the built in function for --fix rather than manual order changes.

TS
1const obj = { zebra: 1, apple: 2, Beta: 3 };