Angular-specific rules

[jpike88]

This is the discussion for handling/discussing all the things that would make biomejs first-in-class for general angular development.

The primary issue: Angular is moving to Signals. Read this if you need a briefing on what Signals are.

The rules here don't just protect against improper Signal usage, but a bunch will be, so they'll be in their own grouping.

Sorted by priority or biggest footguns:

HIGH (4):

• banFunctionPropertyAccess ban property access (e.g. length property) on function-like variables

e.g

myFunction.length    // this is bad, don't allow this

• banReferenceToSelfInSignalUpdate don't allow references to the signal itself in an update, only allow use of the provided parameter in it. this ensures mutation occurs in a predictable and safe way.

e.g

const mySignal = signal<{
	foo: string
}>(undefined);

mySignal.update(v => {
	mySignal().foo = 'test';   // this is a bad idea, we should have used the v parameter!
	return v;
})

• banReturnSameReferenceInSignalUpdate don't allow the returning of the same variable passed in a signal update function, as it won't trigger change detection to other signals that may depend on it. Normally a spread operator is used to force a new object to be referenced.

e.g

const mySignal = signal<{
	foo: string
}>(undefined);

mySignal.update(v => {
	v.foo = 'test';
	return v; // this is bad, we should have used a spread operator like {...v} to force a new reference to be returned, otherwise change 						detection won't be triggered!
})

• readonlySignals all signal-types should be readonly if they're a property of any class, it's too easy to accidentaly set one to 'null' and break everything

e.g

@Component({
	template: `hello`
})
export class MyComponent {

public mySignal = signal(false); // this is bad, it should be a readonly property!
public mySignal2 = input(false); // this is bad, it should be a readonly property!
public mySignal3 = output(false); // this is bad, it should be a readonly property!
public mySignal4 = computed(() => {})); // this is bad, it should be a readonly property!
public mySignal5 = linkedSignal(() => {})); // this is bad, it should be a readonly property!

}

• banFunctionEnumeration ban Object.keys(), Object.values(), Object.entries(), for...in loops, Object.getOwnPropertyNames() and Object.getOwnPropertySymbols() from taking function-like arguments

e.g

const mySignal = signal<{
	foo: string
}>(undefined);

for(const x of Object.keys(mySignal)){   // this is usually bad, enumerating keys of a function is 99% of the time a mistake!
//
}

MEDIUM:

• banFunctionReassignment don't allow a function to be declared using let, or a function property on a class to be replaced
• banFunctionEqualityChecks don't allow function-like variables to be compared to anything else
• banFunctionIsArray don't allow function-like variables to be passed to Array.isArray

LOW:

• privateInjectionProperties all inject statements as a class property should be private
• injectsAtTopOfClasses keep inject calls at the top of a class
• signalsAtTopOfClasses keep all signals at top of class, below injects

// this is WIP

• Support formatting of angular templates :D