Add version info: CLDR, Unicode, Timezone

[srl295]

It could be handy to have some additional ICU version information available, besides just the icu version itself. since the ICU features have more and more applicability to various parts of Node.

These could go into process.versions, or not.
Note that for the CLDR and TimeZone version, we actually need to read data files to get the answer. So, I'd hesitate to just stuff constants into process.versions. Is there a way to lazily-initialize a constant?

Unicode Data Version

 unicode: '9.0'

This gives information about which Unicode Version is included. This would affect which characters are interpreted by regexes, etc.

Implementation: u_getUnicodeVersion() (doesn't actually read any data files to get the result)

CLDR Version

 cldr: "30.0.2"

This is the version of the CLDR data files used for ICU's implementation.

Time Zone Data Version

 tz: "2016g"

This is the version of the iana tz database.

cc: @nodejs/intl

[addaleax]

Is there a way to lazily-initialize a constant?

Yeah, I guess using a getter should work for that, similar to how the builtin modules are defined in the REPL (src)? We might customize util.inspect for process.versions in that case, because things like node -p process.versions are usually expected to provide the full set, e.g. for remote debugging.

(So, yes, I’m okay with using process.versions.)

[jasnell]

I'm +1 for this. Using a getter as @addaleax suggests is the right approach here.. and definite +1 to using process.versions

[bnoordhuis]

Note that for the CLDR and TimeZone version, we actually need to read data files to get the answer.

Aren't those processed at compile time?

[srl295]

Aren't those processed at compile time?

No, they are in the data file. You can actually upgrade the tz version without recompiling, for example. By "data file" this includes linked-in data, but that still has a loading process which includes looking for overrides on disk, intialization, etc. I don't want "all users" to pay for this if we can avoid it. Checking process.versions seems like an appropriate time, since we need to hit the data to find the answer.

@addaleax @jasnell thanks for the help with the getter idea.

[srl295]

I committed a WIP so far. The cldr and tz functions cache their result, so they can be called lazily but may be called repeatedly.

Sample output:

$ ./node -e 'console.dir(process.versions)'
{ http_parser: '2.7.0',
  node: '8.0.0-pre',
  v8: '5.4.500.31',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  unicode: '8.0',
  cldr: '29.0',
  tz: '2016b',
  modules: '51',
  openssl: '1.0.2j' }

[addaleax]

@srl295 You can do it if you see advantages to it, but generally there should be no need to cache things on the C++ side; You can insert code into the getter to remove the getter itself and replace it with the actual value, so for a second access of the property no Node.js code actually gets executed (the bit of code linked above does that, for example).

[srl295]

@addaleax thanks! It's fun to add bound functions! (And I get to contribute actual JavaScript, imagine that…)

• process.binding('icu').getVersion('cldr') returns the version number for, say, cldr. And as you noted, I don't try to cache on the C++ side.

Anyway- TODO's:

• process.binding('icu').getVersion() with no args returns icu,cldr,tz,unicode as a comma separated list. I didn't look into how to send an array down (up?) yet.
• node -p process.versions as noted shows [Getter] for several values. I'm not sure how best to work around this. JSON.stringify(process.versions) returns the full values.

[srl295]

how about an acutal PR also.