Interesting! Which native API are you referring to?

ooops, sorry, I should have mentioned it here. I mentioned it in the message that I linked :)

I'm refering to the native JS API String.prototype.localeCompare that node supports for a long time. I tried a node version as old as v10 locally. Here is a very simple code example:

["a2", "a10", "a1"].sort((a, b) => a.localeCompare(b, undefined, { numeric: true }))
// Result: [ 'a1', 'a2', 'a10' ]

I'm thinking that probably instead of undefined we should use 'en-US' so that it's locale-independent.

Hope this helps

Ah thanks - so this actually isn't Node-specific, it's JS strings in general. That threw me - we support running in browsers and therefore try not to rely on Node-specific APIs.

I tried the suggested change out locally and saw a couple of incorrect errors. For example:

Member a5 should be declared before member a10.

The natural-compare-lite package compares groups of numbers against each other numerically, not alphabetically. That's not the same as using localCompare.

Am I missing something?

I'd like to see your code :) Especially have you used {numeric: true} as an option? That's the secret sauce.

// import naturalCompare from 'natural-compare-lite';

function naturalCompare(a: string, b: string): number {
  return a.localeCompare(b, 'en-US', { numeric: true });
}

We've been strapped for time recently so I'm going to close this. But if you can make a draft PR that shows existing test cases passing with localeCompare, we can reopen. 🙂

My understandng:
natural-compare-lite orders with upper case letters first
localeCompare orders with lower case letters first

Normally we can configure this in localeCompare using caseFirst: "upper" but... I couldn't make it work (not in node, not in Firefox).

We can also decide that localeCompare order is the right one -- this is just a choice after all.

I asked around to colleagues about the issue though.

Sounds good! We can always look at an issue for new sort options if you feel there's a variant that should be added.

I got the bottom of this.

1. localeCompare sorts lexicographically. This means that A and a always come before B and b.
2. the caseFirst option configures whether A comes before or after a. The default is locale-dependent.

Therefore with localeCompare we can't have both the numeric sorting and have all uppercases come before lowercases like the 3rd-party library does.