Feature request - include ISO country codes

[conorot]

It would be useful to add a couple of parameters to the library, specifically the ISO 3166-1 country codes (Alpha 2, Alpha 3 and Numeric) to enable searching based on country.

Proposed to add extra objects like this:

{
    code: 'ZMW',
    number: 967,
    digits: 2,
    currency: 'Zambian kwacha',
    countries: [ 'zambia': {
                              'name': 'zambia',
                              'iso2': 'ZM',
                              'iso3': 'ZMB',
                              'numeric': '894'
                         } ] 
}

I'd propose keeping the base structure and extending it to create an array of objects for each country. This could be a breaking change but would be extendable. The key could be the country name, but also keep this as a value for consistency of use.

This would allow for functionality to be built that allows for searching for currency based on country code.

[eXeDK]

I agree that this valuable information however as you point out this is a breaking change. If you come up with a solution that is not breaking the existing API in a meaningful way I think we should look into it!

[freeall]

I think this might be out of scope for this module. I am not entirely sure though.

[maxsommer]

I would definitely agree this should be done in this library. To make it a non-breaking change this could also be acceptable:

{
  code: 'ZMW',
  number: 967,
  digits: 2,
  currency: 'Zambian kwacha',
  countries: [ 'zambia' ],
  isoCountries: [ 
    {
      'name': 'zambia',
      'iso2': 'ZM',
      'iso3': 'ZMB',
      'numeric': '894'
    } 
  ]
}

[freeall]

@maxsommer that's not a bad idea at all. If you make a PR that would include this, I'll add it. Preferably in a way that could be done automatically whenever there's updates to the data set.

[maxsommer]

@freeall Sure, I'm currently on it. However I've found a few points where I'd love your input.

• What is currently the way to update the data (in data.js)? Was the data somehow imported from the ISO website (e.g. via their exposed XML file)?
• What would you think of automating the update process fully by pulling the data from the Wikipedia pages (if not already done and I overlooked it or was not included in code) or via the ISO homepage?
• Would the Wikpedia pages e.g. for you be a respectable data source? See Wikipedia ISO 4217 and Wikpedia ISO 3166 for reference. The reason I'm proposing this is that ISO is actually charing money for consumption of at least their country code list in structured format see ISO 3166.
• What would you consider a useful data model for the isoCountries property? I based my proposition on the data table found in Wikipedia ISO 3166:

  interface Country {
  name?: string;
  shortname?: string;
  sovereignity?: string;
  iso2?: string;
  iso3?: string;
  numeric?: string;
  subdivisionCode?: string;
  }

---

How should I go from here? I cloned the repository and built a script to update basically all the data (see here) – I think the changes I made there would be breaking however as they would introduce changes to the current dataset (e.g. "Afghani" became "Afghan afghani" because of the data source change). There are multiple ways of going forward for me:

• Keep the current main data set, only pull ISO Country data from Wikipedia and enhance the current dataset via script (aka stay non-breaking)
• Be ok introducing a new major version with modified data set and import data in automated fashion from Wikipedia
• Don't use Wikipedia as datasource at all, switch to official ISO data and e.g. crawl their country codes list and rebuild on top of that

One cool side effect from switching to Wikipedia as data source we could have as a benefit is actually internationalization of the content – the content could be pulled in as many languages as are provided in Wikipedia and be an optional argument when interacting with the library e.g.

const cc = require('currency-codes');
console.log(cc.code('EUR'));
console.log(cc.code('EUR', 'de'));

Of course this doesn't have to be the librarys scope it's for you to decide :) In combination with a Typescript based rewrite and an automatically executed test suite this could be a full new major version as well.

Depending on what your oppinions are I will make according changes and file a pull request. Please have a look at my proposal here

[maxsommer]

Hey @freeall any feedback would be appreciated.

[Spomky]

This is a nice feature I would love to have. Just one question though: why numeric is of type string? Is there any reason to return a string instead a positive integer?

[maxsommer]

@Spomky I kept numberic field a type string because it seems like according to standard there are numeric identifiers with leading 0 such as 020 for Andorra. Seemed unintuitive for me as well and we could also argue this could be handled internally but I'd rather adhere to seemingly standard 😄

[Spomky]

there are numeric identifiers with leading 0 such as 020 for Andorra

OK I was not aware of that. Makes sense to let it as a string. Thanks for the explanation.