rxaviers
commented
7 years ago That would be a problem since the "proposed filter" removes functionality, not locale coverage. Note that cldr-data is a package with this goal in mind: libraries define their dependency on functionality (numers vs dates vs units, etc) and applications define their dependency on locale coverage (modern vs. full).
End users can modify the coverage at install time via the coverage modifiers (either via env vars or package.json properties); but libraries can only define their dependency on cldr version as a whole via cldr-data.
I believe your second PR #41 addresses this problem in a custom way. That should be enough right?
Having said time, perhaps it's time to rethink about cldr-data package. It was built in a time where Unicode didn't published CLDR json in github (https://github.com/unicode-cldr/) nor npm. Now we have those packages per functionality. The problem still is that it's impossible for libraries to define their dependency on a functionality without also defining the locale coverage (i.e., choosing either modern or full). Usually libraries should choose full, because otherwise it doesn't meet the applications need on locale coverage. Anyway, I believe one options is to have various cldr-data like packages, one for each big functionality area, like cldr-data-core, cldr-data-number, cldr-data-date, cldr-data-non-gregorian-date? I'm just throwing out ideas.
sag3ll0
Maybe it was usefull to use minimal combination without additional calendars zip, it reduse download size in half