blakeembrey / array-flatten Goto Github PK

Hey there,

could you please either ship the .d.ts with npm or register it ?

The benchmarked library checks (here) if the first arg is an array. When it is, it provides the args array as the arguments. Essentially unwrapping your fixture.

It appears you knew that and were dealing with it in here, and here.

It seems that no longer works tho. Those functions don't get called and the target functions are called with extra, unintended, arguments.

I noticed this when the "if-depth" benchmark was way faster than the others. I had it show its arguments the first time it ran and it was receiving a 'b' as the second arg. When I looked at "fixtures/large.js" I found that was the second element in the exported (outermost) array.

If I alter your fixtures files to wrap their exported value an extra time then they are used correctly for the flatten suite, but not the arguments/depth suites.

After looking at the source code for benchmarked I haven't seen a way to provide a similar option which will run those "extra wrapping" functions you have.

So, what I've done, for now, is put the current fixtures into a sub-directory named "fixtures/arguments", similar to "code/arguments". Then, created corresponding files in "fixtures/flatten" and "fixtures/depth" which require the ones in "fixtures/arguments" and wraps them. The "flatten" ones are only wrapped into an array. The "depth" ones are wrapped and a second element of 4 provided; same as what you had in the benchmark main file.

Right now the package contains these files, which I think can be safely excluded:

• .npmignore
• .travis.yml
• test.js

The test file and travis config could at least be added to the .npmignore or you can remove the .npmignore and use the files key in package.json for an even slimmer package :)

{
  "files": [
    "array-flatten.js",
    "LICENSE",
    "README.md"
  ]
}

(you don't have to add README.md explicitly)

Getting a ts error: Type instantiation is excessively deep and possibly infinite. ts(2589)

Minimal example:

import {flatten} from 'array-flatten';

const nestedArray = [
    ['c', 'd'],
    ['e', 'f'],
];
const concatArray = ['a', 'b'].concat(flatten(nestedArray)); // error is here
console.log(concatArray);
// [ 'a', 'b', 'c', 'd', 'e', 'f' ]

Workaround:

import {flatten} from 'array-flatten';

const nestedArray = [
    ['c', 'd'],
    ['e', 'f'],
];
// save off the flattened array first
const flattenedArray = flatten(nestedArray);
const concatArray = ['a', 'b'].concat(flattenedArray); // no error
console.log(concatArray);
// [ 'a', 'b', 'c', 'd', 'e', 'f' ]

Seems like a pretty weird edge case. I haven't looked into why it's happening. If it's not worth fixing, at least it's documented now 🤷‍♂.

Versions

• array-flatten version: 2.1.0
• typescript version: 2.1.5

Problem

When I try to compile the following example

import * as flatten from 'array-flatten';

const arr = flatten.depth<number>([[[1, 2]]], 1);
arr.push(1);

I get the error:

index.ts(4,5): error TS2339: Property 'push' does not exist on type 'NestedArray<number>'.

Expected behavior

No errors. NestedArray interface has methods from Array. Maybe define NestedArray like this:

interface NestedArray<T> extends Array<T | NestedArray<T>> {}

?

Since internally, this is assumed to be an array, (or at least array-like) it takes a string like abc and creates [ 'a', 'b', 'c' ]. This forces me to always wrap my arguments in an array literal:

flatten('abc');
// [ 'a', 'b', 'c' ]

flatten([ 'abc' ]);
// [ 'abc' ]

Would it be all right if strings were a special case that are assumed to be an array element? My hunch is that this is what most people would expect with strings, but I could be wrong.

Hi @blakeembrey!

This module is really popular! It's also nice and small, but I was wondering if you'd be open to providing a JS Modules version in addition to CommonJS? I'd be happy to PR. Let me know if you have a preference for tooling/etc.

... in favor of [].flat() & [].flatMap() or any polyfill