Missing buildLocalizeArrayFn module

[ericreis]

I was trying to dynamically import locales from date-fns package and bumped into the following error:

Module not found: Can't resolve '../../../_lib/buildLocalizeArrayFn/index.js' in '/Users/ericreis/dev/vtex/test/node_modules/date-fns/locale/ar-DZ/_lib/localize'

Here is the code I'm using to perform the dynamic import:

const locale = 'en-GB'
import(`date-fns/locale/${locale}/index.js`).then(
  data => {
    console.log(data)
  })

I searched everywhere for this buildLocalizeArrayFnfolder, but I didn't find it anywhere. Is it a bug? If not, could anyone point to me what I am doing wrong?

[TwoDCube]

Because you used en-GB I assume you're using date-fns@next. By doing your import like this, it tries to find every file named index.js under the locale directory (even those with depth > 1!, the locale variable can contain a /). And there are some languages containing old/unused code which are not imported by date-fns but your dynamic import tries to use them too thus giving you errors.

[ericreis]

I am using v2.0.0alpha23. What would be the correct way to dinamically import the package then?

[ericreis]

But my point actually is: Does this '../../../_lib/buildLocalizeArrayFn/index.js' require (for example in line 2 here) make any sense? I think it does not since there is no sign of this path (buildLocalizeArrayFn folder) anywhere in the project (even in old versions).

[TwoDCube]

I currently couldn't find a way to import them properly. At the weekend I'll create a PR to export the languages from single files instead of folders so this depth thing won't be a problem. (Something like angular does here)

So you would write something like:

import(`date-fns/locales/${locale}.js`)

This way there are no folders and depths to worry about. What do you think?

[TwoDCube]

There was a folder like that, see this

[ericreis]

This way there are no folders and depths to worry about. What do you think?

I personally prefer this way too.

There was a folder like that, see this

Maybe that's the folder that is missing now.

[ericreis]

I'll try adding that folder to my current test project and post the updates.

Edit 1: There are actually many folders missing. I am going to use this reference here to make the errors disappear.

Edit 2: After adding buildLocalizeArrayFn, buildParseFn and parseDecimalfolders now the error is a bit different:

./node_modules/date-fns/locale/be/build_format_locale/index.js
Module not found: Can't resolve '../../_lib/build_formatting_tokens_reg_exp/index.js' in '/Users/ericreis/dev/vtex/test/node_modules/date-fns/locale/be/build_format_locale'

Maybe it's referring to this. @TwoDCube can you confirm that?

[ericreis]

I think I managed to fix all the errors by adding the buildLocalizeArrayFn, buildParseFn, parseDecimaland build_formatting_tokens_reg_exp folders. This last one I assumed that it used to be this.

[ericreis]

For my test project it worked perfectly. I tested it by using the react-datepicker component that depends on date-fns.

Tomorrow I'll work on a PR for these files and check if everything is alright.

[TwoDCube]

I don't think it's a great idea to just recover those deleted directories. Probably they had a reason to remove those folders.

Also I think it would still try to include the index.js -s from deeper directories too. I'll also make a PR to show my idea too.

[ericreis]

I don't think it's a great idea to just recover those deleted directories. Probably they had a reason to remove those folders.

I totally agree with you. I made those changes just to check if we would have any other errors regarding dynamic imports and it appears we don't.

Also I think it would still try to include the index.js -s from deeper directories too.

Yeah, it does.

I'll also make a PR to show my idea too.

I personally think that the idea of having all ${locale}.js files in a single folder with no deeper levels is the way to go. If you need any help in the PR, just let me know.

[kossnocorp]

I personally think that the idea of having all ${locale}.js files in a single folder with no deeper levels is the way to go. If you need any help in the PR, just let me know.

@ericreis please don't do that. I don't have time right now to dive deep into your problem, but this solution won't be accepted.

First of all, there are unsupported locales that you don't want to import anyway. You can see the list here: https://github.com/date-fns/date-fns/blob/master/outdatedLocales.json. Secondly, the locales should stay modular.

[ericreis]

@kossnocorp perhaps then these locales should me moved to a separate location? Dynamic import is a powerful feature that right now is breaking due to outdated files in modules that won’t even be called.

[developdeez]

Any solution to this? I have the same issue.

loadLocale = () => {
let lang = "en-US"
import("date-fns/locale/" + lang)
.then(locale => {
console.log(locale);
registerLocale(locale.toString(), locale);
})
.catch(console.log("Date lang Error"));
};

[san-pblr-gct]

I am getting compilation error due to unsupported locales present inside locale folder. Any solution?

[san-pblr-gct]

I did a work around for alpha 27 version by considering active locales

I created supportingLanguages.js with

const supportedLanguages = {
  af: async () => await import("date-fns/locale/af/index.js"),
  arSA: async () => await import("date-fns/locale/ar-SA/index.js"),
  bn: async () => await import("date-fns/locale/bn/index.js"),
  de: async () => await import("date-fns/locale/de/index.js"),
  el: async () => await import("date-fns/locale/el/index.js"),
  enCA: async () => await import("date-fns/locale/en-CA/index.js"),
  enGB: async () => await import("date-fns/locale/en-GB/index.js"),
  enUS: async () => await import("date-fns/locale/en-US/index.js"),
  eo: async () => await import("date-fns/locale/eo/index.js"),
  es: async () => await import("date-fns/locale/es/index.js"),
  et: async () => await import("date-fns/locale/et/index.js"),
  fr: async () => await import("date-fns/locale/fr/index.js"),
  gl: async () => await import("date-fns/locale/gl/index.js"),
  he: async () => await import("date-fns/locale/he/index.js"),
  hu: async () => await import("date-fns/locale/hu/index.js"),
  it: async () => await import("date-fns/locale/it/index.js"),
  ja: async () => await import("date-fns/locale/ja/index.js"),
  lt: async () => await import("date-fns/locale/lt/index.js"),
  nb: async () => await import("date-fns/locale/nb/index.js"),
  nl: async () => await import("date-fns/locale/nl/index.js"),
  pt: async () => await import("date-fns/locale/pt/index.js"),
  ptBR: async () => await import("date-fns/locale/pt-BR/index.js"),
  ru: async () => await import("date-fns/locale/ru/index.js"),
  sv: async () => await import("date-fns/locale/sv/index.js"),
  uk: async () => await import("date-fns/locale/uk/index.js"),
  vi: async () => await import("date-fns/locale/vi/index.js"),
  zhCN: async () => await import("date-fns/locale/zh-CN/index.js")
};


export default supportedLanguages;

and then where ever i wanted to import

 supportedLanguages[language]().then(localeFile => {
     //do something
    });

[aliciacatalina]

I'm facing the same issue when trying to dynamically import a locale file, are there any plans to remove the outdated locales?

[kossnocorp]

I've released a fix for this issue as v2.0.0-alpha.34: https://gist.github.com/kossnocorp/a307a464760b405bb78ef5020a4ab136#v200-alpha34