RFC: This module needs a complete overhaul

[rxaviers]

trafficstars

Does it still make sense to download files or should it leverage the official unicode npm modules? https://github.com/unicode-org/cldr-json/tree/main/cldr-json

• If yes, i.e., let's leverage the official unicode npm modules: should this package have a direct dependency on those?
  • If yes, i.e., let's have a direct dependency
    • It'll probably lose the full vs modern coverage aspect. Does it matter?
    • It still has the cons of maintenance: requires a new update (even if bump ups) for every CLDR update
  • If not, i.e., let's assume user will install unicode CLDR modules themselves
    • This module could be an interface only for whatever it finds installed, i.e., the API all(), entireMainFor(), entireSupplemental() may still work leveraging require.resolve and testing to figure out the installed modules. ⬅ (my personal preference as of now)
• If not, i.e., let's keep downloading files
  • Fix npm/node post-install problem (various related open issues)
  • Fix #28

[compulim]

Same to me. It should leverage the official NPM package and allow developers to pick CLDR versions which they find suitable. A constant chore of keeping bumping is automatable via GitHub Actions. But this impact reliability as we never know if a future version of CLDR will be as friendly as today's.

As Unicode team already published CLDR data in NPM fashion, can globalize depends on them directly?