Reverse order back for the returned paths

[chrisblossom]

#95 might be considered a breaking change since the files are sorted in reverse order. I am not sure this reverts the old order exactly, but thought I'd put this PR in to let you decide what's best.

[sindresorhus]

Why do you think it’s a breaking change?

[chrisblossom]

Currently if someone has code like this:

test('removes files', async () => {
    // assume these files exist
    // './remove-these-files/a.js'
    // './remove-these-files/b.js'
    const filesRemoved = await del(['**/*'], {
        cwd: path.resolve('./remove-these-files'),
    });

    expect(filesRemoved).toEqual([
        path.resolve('./remove-these-files/a.js'),
        path.resolve('./remove-these-files/b.js'),
    ]);
});

Their test will fail after this update.

Not 100% saying it is breaking, just something to consider. I noticed it on one of my projects.

[sindresorhus]

The order was already unstable as globbing is inherently not stable, and the order could change in patch releases because of glob optimizations. So yes, makes sense to sort it back for consistency.

[chrisblossom]

The order was already unstable as globbing is inherently not stable, and the order could change in patch releases because of glob optimizations. So yes, makes sense to sort it back for consistency.

After thinking about this comment I think this PR should be updated to use .sort((a, b) => a.localeCompare(b)) instead of .reverse() to consistently return the same order every time.

Should I put another PR in for this, or do you want to amend this merge/leave as is?

[sindresorhus]

Sure, PR welcome.