prefer-array-literal: how can one specify the size of the array?

[IllusionMH]

how can one specify the size of the array?

const foo = new Array(10)
?

Originally posted by @ogiexela in #110 (comment)

[IllusionMH]

@ogiexela it depends on case what you want to achieve.

Using new Array rarely have any advantages (e.g. it won't create optimized arrays thread), however behaves differently if there is one or more arguments that leads to errors. Therefore this rule was created.

In general case it is better to use [] and fill it with values later (see thread).

If you really need to create array in this way you can disable error for this line with rule flags e.g. // tslint:disable-next-line:prefer-array-literal on previos line.

[ogiexela]

What about the case where I already know the exact size that I need the array to be.
Then according to this per-defined size array performs better.
Or am I missing something?

https://jsperf.com/push-method-vs-setting-via-key/23

[IllusionMH]

It will depend on your use cases. As mentioned in this tweet you see that new Array will be faster to create array and fill it with index access.

If your application creates new big arrays really often and usually uses regular for loop to iterate though this array - new Arraly(length) most likely will be better fo performance.
And you should use // tslint:disable-next-line:prefer-array-literal because you are sure that you are passing 1 element and expect to have array of passed length.

However if big arrays are created only once (or in rare ocassions) and app heavily relies on freqest uses of .map, .forEach etc. - those loops mig be slower that in case when you use .push to keep array packed.

Anyway - if performance is your concern you should check which of these both approaches will be faster in your case.

---

Main reason for this rule - avoid different/unexpected behavior between cases new Array(1000), new Array(1000, 2000), and new Array('1000'). And new Array(length) has its pros and cons for performance in different cases.

If you need reallocate array - better to disable rule for that single line (only option available ATM).

---

If I understand correctly - similar rule in ESLint (and migrated rule for TS) allows Array constructors with 1 argument. May be makes sense to add flag that will allow this use cases?

@JoshuaKGoldberg what do you think?

[JoshuaKGoldberg]

Sure, seems reasonable to add a flag to allow just the case of the constructor with 1 argument. The flag should allow arrays to be created with new only when there is a single argument of type number.

A few thoughts:

• This requires the type checker, for the case of variables being used instead of literals. The rule should therefore become an optionally typed rule that requires the type checker if this option is enabled.

• Types that can include non-number types, such as union types and generic types not bound to extend a numeric type, should not be allowed:

  // Accidentally creates array of size (item) if TItem is numeric
  function createArrayOfSizeOne<TItem>(item: TItem) {
      return new Array(item);
  }

[IllusionMH]

6.2.0-beta was published to npm that allows this behavior.
You can install latest version with npm install tslint-microsoft-contrib@beta and list restriction for invocations with single argument with "prefer-array-literal": [true, {"allow-size-argument": true}] in your tslint.json

[astorije]

@IllusionMH, @JoshuaKGoldberg, would you be open to default this parameter to true? It seems like a reasonable thing to allow by default.

[JoshuaKGoldberg]

@astorije I think so, yeah. Agreed it's reasonable. #678