localeCompare changes behavior between versions

[tmcw]

Example:

~/src/documentation〉nvm use v0.10
Now using node v0.10.39 (npm v3.3.9)
~/src/documentation〉node -e "console.log('a'.localeCompare('B'))"
31
~/src/documentation〉nvm use v5
Now using node v5.1.0 (npm v3.3.12)
~/src/documentation〉node -e "console.log('a'.localeCompare('B'))"
-1

It seems likely that this change is due to an upstream V8 changes, but I can't seem to find any issues in the v8 tracker or this one discussing behavioral change with respect to the String.prototype.localeCompare method.

[mscdex]

I just tried your example on both v0.10.40 and v5.1.0 on Linux and I get 31 for both versions.

[Trott]

@mscdex Tried with v5.1.0 on OS X and got -1. So, maybe specific to OS X?

This is also what I get in Chrome on OS X, so if there is an issue here, it's probably v8 as the OP sorta suggests...

[jorangreef]

In the long run, it's also possible for this to happen as things like the Unicode standard advance, or as locale tables are updated. It's probably going to be rare, but any application relying on localeCompare should be aware of it.

[bnoordhuis]

The version of V8 in v0.10 doesn't really support localization. The v4.x and v5.x release builds on the other hand are built with proper ICU (i18n) support.

Note that omitting the locales argument to .localeCompare() means its behavior will be platform-specific.

[cjihrig]

It sounds as if there isn't anything actionable to do here.

[ChALkeR]

/cc @srl295, I guess.

[srl295]

No, I think localeCompare() is doing the right thing here (for whatever your locale is). To expand on what @bnoordhuis noted, it's not just platform-specific, it's locale-specific.

$ npm install full-icu
$ export NODE_ICU_DATA=node_modules/full-icu
$ env LC_ALL=da node -e 'console.log("å".localeCompare("z"))'
1
$ env LC_ALL=en node -e 'console.log("å".localeCompare("z"))'
-1

( https://en.wikipedia.org/wiki/Danish_language#Writing_system )