This rule raises an issue when code converts a Set to an array using the spread operator and then accesses the length property, instead of directly using the Set’s size property.

Why is this an issue?

When you need to get the number of elements in a Set, accessing the size property directly is more efficient than first converting the Set to an array.

The pattern […​new Set(array)].length creates unnecessary overhead because:

• The spread operator …​ creates a new array from the Set
• This array creation requires additional memory allocation
• The operation takes more time than simply reading the size property

Sets have a built-in size property that provides the exact same information without any conversion. This property is specifically designed for this purpose and is both faster and more semantically correct.

Using Set#size directly makes your code more readable because it clearly expresses the intent: you want to know how many unique elements there are, not create an array.

What is the potential impact?

This issue causes unnecessary performance overhead due to array creation and memory allocation. While the impact may be minimal for small datasets, it can become significant when working with large Sets or when this operation is performed frequently in loops or hot code paths.

How to fix?

Replace the array conversion and length access with direct access to the Set’s size property.

Non-compliant code example

function isUnique(array) {
	return [...new Set(array)].length === array.length; // Noncompliant
}

Compliant code example

function isUnique(array) {
	return new Set(array).size === array.length;
}

Documentation

• eslint-plugin-unicorn - Rule prefer-set-size
• MDN - Set.prototype.size - Official documentation for the Set size property
• MDN - Set - Complete reference for JavaScript Set objects