Rule proposal: no-array-from-fill-map

[htunnicliff]

Description

When creating an array of a predetermined length (e.g. with Array.from({ length: 5 })), it is common to insert items at each index and/or fill it with items.

I'd like to propose using the built-in mapfn argument for Array.from(iterable, mapfn) in lieu of Array#map() or Array#flatMap() on a newly-created arrays,.

These are the scenarios I think this rule should take into account:

• When creating an array with Array.from()
  • If .fill().map() is chained to it, suggest moving the map callback into the mapfn argument
  • If .fill().flatMap() is chained to it, suggest moving the flat map callback into the mapfn argument and appending .flat()

If desired, the flatMap portion of the rule could be a configurable option (e.g. allowFlatMap).

Examples

// ❌
Array.from({ length: 5 })
  .fill(null)
  .map((_, index) => `Item number: ${index}`);

// ✅
Array.from(
  { length: 5 }, 
  (_, index) => `Item number: ${index}`
);

// ❌
Array.from({ length: 5 })
  .fill(null)
  .flatMap((_, index) => [["something", index]]);

// ✅
Array.from(
  { length: 5 }, 
  (_, index) =>  [["something", index]]
).flat();

// ❌
Array.from({ length: 5 })
  .fill({ something: "special" });
// type: Array<unknown>

// ✅
Array.from(
  { length: 5 }, 
  () => ({ something: "special })
);
// type: Array<{ something: string }>


// ✅
Array.from<{ something: string }>({ length: 5 })
  .fill({ something: 'special' });
// type: Array<{ something: string }>

Proposed rule name

One of:

• no-array-from-fill-map
• prefer-array-from-map-fn
• prefer-array-from-init-fn

Additional Info

No response

[fregante]

Somewhat related to:

• Rule proposal: Prefer Array.from(arr, mapFn) over Array.from(arr).map(mapFn) #2357

[fregante]

// ❌
Array.from({ length: 5 })
  .fill({ something: "special" });
// type: Array<unknown>

// ✅
Array.from(
  { length: 5 }, 
  () => ({ something: "special })
);
// type: Array<{ something: string }>

Note that this produces two different results. The first one uses a single shared object whereas the second one generates a new one for each item.

[htunnicliff]

// ❌
Array.from({ length: 5 })
  .fill({ something: "special" });
// type: Array<unknown>

// ✅
Array.from(
  { length: 5 }, 
  () => ({ something: "special })
);
// type: Array<{ something: string }>

Note that this produces two different results. The first one uses a single shared object whereas the second one generates a new one for each item.

This is one of the reasons I think this rule is helpful, as it prevents the first kind of behavior from occuring

[fregante]

Yes, but why accept it in your second ✅ example?

Anyway the rule could be called no-array-from-fill since in this scenario there's no .map(). It wouldn't block .fill() entirely, but it does still target .fill() exclusively.