Moment: aux États-Unis, local

Il y a une locale en , elle ne vient tout simplement pas dans un fichier séparé. Il est très bien accepté par moment().locale() et moment.locale() :

moment.locale('fr')
"fr"
moment().format("LLLL")
"vendredi 25 novembre 2016 03:39"
moment.locale('en')
"en"
moment().format("LLLL")
"Friday, November 25, 2016 3:39 AM"

en-US fonctionne aussi parce que nous recherchons une correspondance moins spécifique et que la locale en est l'anglais américain:

moment.locale('en-GB')
"en-gb"
moment().format("LLLL")
"Friday, 25 November 2016 03:40"
moment.locale('en-US')
"en"
moment().format("LLLL")
"Friday, November 25, 2016 3:40 AM"

Je ne l'achète pas; considérez le cas où la locale est détectée à partir de l'environnement, puis un chemin de dépôt requis est construit pour charger moment / locale / $ {foundlocale}. Si cette variable est "en" ou "en-us", alors requirejs échouera à charger un fichier (obtient un 404). S'il est détecté comme «de», le fichier se chargera.

Le chargeur de paramètres régionaux de @eigood Moment sait qu'il a déjà l'anglais et n'essaye pas de le charger à partir d'un fichier externe.

@icambron Je ne pense pas que vous ayez raison de marcher dans l'arborescence lorsque l'utilisateur passe «en-US» comme locale. En fait, je suis en train de le déboguer et il se brise parce que vous ne marchez PAS dans l'arbre.
Mon cas d'utilisation est que j'appelle moment.utc (myDate, myFormat, locale, true) où locale est juste une seule chaîne 'en-US'. Étant donné que cette chaîne ne peut pas être importée (car il n'y a pas de fichier pour elle) mais qu'il ne s'agit pas d'un tableau, elle tente d'exiger les paramètres régionaux, puis interrompt les environnements de production.
Il me semble que le meilleur comportement réel serait d'inclure réellement en-US dans la liste des locales présentes par défaut (il n'est pas là pour le moment, juste en lui-même).

@steveccable Eh bien, il essaie de le charger, juste au cas où vous auriez une localisation plus spécifique. Lorsqu'il échoue, il essaie simplement "en" et réussit. Je pense que la déconnexion est simplement que le fait de ne pas charger "en-US" se brise pour vous. Rien n'est censé exploser ici; il est juste censé échouer gracieusement et passer à l'option suivante. Vous devrez donc m'en dire plus sur votre environnement: qu'est-ce qui ne va pas précisément?

@icambron Mon environnement est une application React Native utilisant npm pour contrôler mes dépendances, et j'ai pu répliquer l'échec même dans des exemples d'application minimaux. Le problème est que dans la fonction loadLocale, il tente d'exiger ('./ locale /' + nom) où nom est en-US, et que require échoue. Lorsque cette demande échoue dans une version de version, l'application se bloque avec une trace de pile le long des lignes suivantes:

E/ReactNativeJS: Requiring unknown module "./locale/en-us".
E/AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
                                                                Process: com.myApp, PID: 30054
                                                                com.facebook.react.common.JavascriptException: Requiring unknown module "./locale/en-US"., stack:
                                                                o<strong i="7">@2</strong>:742
                                                                n<strong i="8">@2</strong>:426
                                                                i<strong i="9">@2</strong>:278
                                                                t<strong i="10">@2</strong>:210
                                                                Xe<strong i="11">@648</strong>:16702
                                                                nt<strong i="12">@648</strong>:17804
                                                                gt<strong i="13">@648</strong>:22583
                                                                yt<strong i="14">@648</strong>:22460
                                                                wt<strong i="15">@648</strong>:23200
                                                                c<strong i="16">@648</strong>:1112
                                                                parse<strong i="17">@645</strong>:1536
                                                                render<strong i="18">@643</strong>:2923
                                                                _renderValidatedComponentWithoutOwnerOrContext<strong i="19">@141</strong>:7295
                                                                _renderValidatedComponent<strong i="20">@141</strong>:7462
                                                                performInitialMount<strong i="21">@141</strong>:3012
                                                                mountComponent<strong i="22">@141</strong>:2056
                                                                mountComponent<strong i="23">@132</strong>:205
                                                                performInitialMount<strong i="24">@141</strong>:3162
                                                                mountComponent<strong i="25">@141</strong>:2056
                                                                mountComponent<strong i="26">@132</strong>:205
                                                                performInitialMount<strong i="27">@141</strong>:3162
                                                                mountComponent<strong i="28">@141</strong>:2056
                                                                mountComponent<strong i="29">@132</strong>:205

En parcourant le code, puisque getLocale voit que ma clé ('en-US') n'est pas un tableau, elle tombe dans loadLocale sans jamais essayer de faire correspondre 'en', ce qui ne se produirait que si elle allait dans la fonction chooseLocale.

EDIT: Après avoir regardé un peu plus attentivement la fonction chooseLocale, il essaierait tout d'abord de choisir `` en-US '', puis échouerait le require avant d'essayer `` en '', de sorte que le besoin échoué conduisant à une application en panne se produirait toujours même si c'était un tableau.
Il est également étrange que l'endroit où il se brise soit à l'intérieur d'un try / catch, mais provoque quand même un crash. C'est en fait la chose vraiment déconcertante ici.

EDIT 2: Notez que le require échoue correctement dans une version de débogage (__DEV__), puis il revient à utiliser «en». Je ne sais pas pourquoi require est tellement plus explosif dans __PROD__, mais il est définitivement en train de casser ici dans le moment.

EDIT 3: De la documentation require js, "Si vous n'exprimez pas les dépendances, vous obtiendrez probablement des erreurs de chargement car RequireJS charge les scripts de manière asynchrone et dans le désordre pour la vitesse." Il est donc peu probable que try / catch nous sauve ici, car try / catch n'aide vraiment que les erreurs synchrones.

Donc, après y avoir travaillé un peu, j'ai une solution de contournement (loin d'être idéale). Fondamentalement, chaque fois que mon code essaie de passer dans une locale de «en-US», je l'intercepte et je passe à la place dans une locale de «en». Les autres paramètres régionaux sont autorisés à passer inchangés.

Cela dit, je pense toujours qu'il est problématique qu'il ne puisse pas trouver en-US ni qu'il ne l'ait déjà par défaut, et vous ne pouvez pas l'inclure spécifiquement comme vous le pouvez avec d'autres paramètres régionaux pour éviter de ne pas le trouver lorsqu'il est réellement appelé sur.

@steveccable

Il est également étrange que l'endroit où il se brise soit à l'intérieur d'un try / catch, mais provoque quand même un crash. C'est en fait la chose vraiment déconcertante ici.

Oui, c'est ce que je dis. J'essaie de comprendre pourquoi un appel de demande échoué serait catastrophique. Je n'aiderais pas à coder en dur en connaissant en-US ; nous aurions toujours un échec similaire dans tout autre cas de repli. c'est-à-dire que cela n'a rien à voir avec en étant un cas spécial, mais plutôt avec le processus de secours qui ne fonctionne pas du tout dans votre environnement.

En travaillant dessus, il semble que React Native ne gère pas l'échec des besoins aussi gracieusement que nous pourrions le souhaiter. Vous avez raison de dire que cela n'a rien à voir avec le fait d'être un cas spécial, et la seule raison pour laquelle il semblait que c'était spécial était qu'il n'y avait aucun moyen d'empêcher l'échec de l'exigence en-US (puisque nous ne pouvons pas l'importer directement comme avec d'autres paramètres régionaux). Comme mentionné dans la dernière modification, le try / catch ne fonctionne pas car il échoue de manière asynchrone.
Pour l'instant, la solution de contournement que j'ai mentionnée ci-dessus consistant simplement à nettoyer les paramètres régionaux de «en-US» fonctionne pour mes besoins.

le try / catch ne fonctionne pas car il échoue de manière asynchrone

Oh, j'ai raté cette modification. Cela allait être aussi ma supposition.

@steveccable
Je ne sais pas si vous rencontrez toujours le problème, mais les mêmes plantages dans la version finale (bien qu'avec les paramètres régionaux français) ont consommé une journée de travail pour moi 😢

E/ReactNativeJS: Requiring unknown module "./locale/fr".
(...)

Je l'ai résolu avec:

import 'moment/locale/fr';

Peut-être que ça aide

La solution de contournement de la désinfection de l'entrée locale est correcte, mais c'est vraiment effrayant de savoir qu'un require () natif de réaction peut échouer de manière asynchrone n'importe où et il n'y a aucun moyen de l'attraper. De plus, si j'envoie une locale inexistante ou une chaîne aléatoire (disons 'blah-blah'), cela signifie que l'application se bloque et que je ne peux pas gérer l'erreur nulle part. Je dois donc vérifier de manière défensive que personne ne déclenche ce bug.

J'ai eu des problèmes après la version 2.19.2 voici ce qui a changé avec cette version https://github.com/moment/moment/compare/29afed6...328d51e la fonction updateLocale a commencé à utiliser loadLocale en interne qui à son tour utilise une chaîne dynamique https : //github.com/moment/moment/blob/fea48bb69eda8c0459915d6aa66a910a4d43a55b/moment.js#L1845

Je suppose que cela échoue dans la réaction native car là, vous ne pouvez pas exiger de fichiers dynamiquement par variable https://github.com/facebook/react-native/issues/6391

Dans mon cas particulier, j'importe le fichier en-gb donc il devrait être trouvé dans locales[name] au moment où j'appelle moment.locale. Je ne sais pas pourquoi il est nécessaire.

Je ne sais pas si RN est une priorité ou non, mais le moment pour RN sera interrompu pendant des mois.

Avec tout cela, il semble que Facebook # 69 soit la solution la plus productive pour débloquer tout le monde. Je vais parler à @jeanlauliac et nous verrons si nous pouvons le fusionner lundi.

Juste pour donner un peu de contexte: il existe plusieurs raisons pour lesquelles nous ne prenons pas en charge les dépendances dynamiques. Tout d'abord, l'analyse statique est interrompue lorsqu'elle requiert des modules de manière dynamique. Deuxièmement, lorsque vous utilisez Dynamic Requiert, le module réel que vous recherchez peut ne pas être disponible. Cela peut entraîner des problèmes majeurs en production qui empêcheraient les utilisateurs d'utiliser nos applications, comme par exemple nous pourrions casser Facebook. Nous avons eu des problèmes comme celui-ci dans le passé et ce n'est pas amusant à gérer. Metro est intentionnellement avisé d'empêcher les gens de faire des choses qui causeront de la douleur aux utilisateurs.

Enfin, nous comprenons que ce dépôt open source n'est pas en très bon état pour le moment. La bonne nouvelle est qu'il n'y a jamais eu plus de personnes chez FB travaillant sur Metro, et nous avons un certain nombre de changements majeurs en magasin pour améliorer Metro une tonne, mais la mauvaise nouvelle est qu'il y a des problèmes urgents que nous devons résoudre sans aucun rapport. à l'open source. Nous espérons que dans quelques mois, ce repo sera dans un bien meilleur état et qu'il sera plus facile d'y contribuer. Donnez-nous du temps s'il vous plaît.

Pour RN, je l'ai fait fonctionner en mode release en supprimant la première partie de la locale (probablement quel moment fait derrière les écrans quand il ne parvient pas à charger la locale "xx-XX"). Dans l'extrait de code suivant, locale est la langue de votre appareil sous la forme «xx-XX».

moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-')))

C'est un comportement étrange.

https://stackoverflow.com/a/47260841/175825 vous devez importer une locale spécifique pour que l'écosystème puisse les consommer.

À cause de cette magie, je ne peux pas faire en sorte que react-big-calendar affiche des dates telles que mm/yy utilisant BigCalendar.momentLocalizer() car il s'attend à ce que les paramètres régionaux soient chargés.

Je pourrais ouvrir un problème avec react-big-calendar, mais qu'en est-il de la prochaine bibliothèque que je rencontre qui attend une locale spécifique? Et le suivant?

Ajoutez simplement en-us locale et utilisez par défaut magic.

Ajoutez simplement les paramètres régionaux en-us et utilisez par défaut la magie.

Cela ne résoudra pas le problème, il existe des langues comme l'espagnol ( es-ES => es ) qui effectuent un repli automatique.

Pour tous ceux qui recherchent toujours une solution, cela peut aider à atténuer le problème (à l'exception de quelques cas extrêmes) mais ne résoudra pas le problème racine de RN provoquant un crash lors de la tentative de capture require :

import moment from 'moment/min/moment-with-locales.min.js';

// locale is the locale detected by react-native-device-info
// ts is the time
export const formatTime = (locale, ts) => {
const m = moment.utc(ts);
locale = chooseMomentLocale(locale);
m.locale(locale);
// other logic to determine whether to show the time as "9:43 pm", "yesterday", or "7/8/2018"

return formattedTime;
}

/**
 * Checks if the device locale is available in moment and returns the locale to be loaded
 * <strong i="7">@param</strong>  {string} locale locale to be checked
 * <strong i="8">@return</strong> {string}        locale to be loaded by moment
 */
const chooseMomentLocale = (locale) => {
  // make the locale lower case 
  // will fix crashes caused by "en-GB" (instead of "en-gb") not being found
  locale = locale.toLowerCase();  
  if (moment.locales().includes(locale)) { // check if the locale is included in the array returned by `locales()` which (in this case) tells us which locales moment will support
    return locale;
  } else if (moment.locales().includes(locale.substring(0, 2))) { 
    // check if the first two letters of the locale are included in the array returned by `locales()` which (in this case) tells us which locales moment will support
    // will fixes crashes caused by "en-US" not being found, as we'll tell moment to load "en" instead
    return locale.substring(0, 2);
  }
    // use "en-gb" (the default language and locale for my app) as a fallback if we can't find any other locale
    return 'en-gb'; 
};

J'ai également rencontré ce problème en utilisant React Native et j'ai pu l'éviter en incluant tous les paramètres régionaux à côté de Moment, c'est-à-dire

import moment from 'moment'
import 'moment/min/locales'

(Alternativement, moment/min/moment-with-locales est également fourni mais il n'était pas compatible avec certains de nos autres formateurs.)

C'est un problème très ennuyeux.

L'intérêt des locales n'est-il pas que vous n'ayez même pas à y penser, et certainement pas de coder en dur «en-US» dans votre code simplement parce que VOUS êtes aux États-Unis? Je ne comprends pas pourquoi lors de la demande d'un paramètre régional «en-US», il ne peut pas simplement le prendre. Provoque les gens sans fin de maux de tête.

J'ai résolu ce problème il y a un an mais j'ai complètement oublié comment, alors je dois tout recommencer. (J'utilise un sélecteur de date dans Angular et je mets simplement l'implémentation minimale en explosion avec cette erreur).

J'obtiens cela dans Angular en essayant d'utiliser le sélecteur de date / heure. Si je règle la LOCALE sur quelque chose comme en-GB, cela fonctionne bien mais sans rien spécifier, j'obtiens ceci. J'aimerais pouvoir trouver la bonne façon de résoudre ce problème

Pour RN, je l'ai fait fonctionner en mode release en supprimant la première partie de la locale (probablement quel moment fait derrière les écrans quand il ne parvient pas à charger la locale "xx-XX"). Dans l'extrait suivant, locale est la langue de votre appareil sous la forme "xx-XX".

moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-')))

Cette solution fonctionne pour moi, en utilisant i18n et momentjs comme ceci:

// imports:
import moment from 'moment';
import i18n from './i18n';
import 'moment/locale/fr';

// constructor: 
moment.locale(i18n.locale.indexOf('-') === -1 ? i18n.locale : i18n.locale.substr(0, i18n.locale.indexOf('-')));

J'expérimente toujours ce problème avec la version "moment": "^ 2.22.2",
Une correction dans la dernière version?

Je vais intervenir sur cette question.

1. traiter en-US comme une forme différente par défaut cachée des autres est une mauvaise conception.
2. sans locale en-us, je ne sais pas quelle version de CDN utiliser.
3. Moment semble impressionnant, mais je trouve mal une autre solution car en-US n'étant pas la même chose que les autres locales, c'est une mauvaise odeur de code.

J'ai également eu cette erreur de réaction native en production après avoir fait un joli développement construit qui fonctionne parfaitement.
Résolu le problème avec la solution proposée par @adesmet et le refactor suivant:

function parseLocaleForMoment (language) {
  if (language.indexOf('-') === -1) return language
  else return language.substr(0, language.indexOf('-'))
}

On dirait que RN craint tellement avec le moment qu'il est plus facile d'écrire simplement un formateur natif. Probablement juste une ligne de code, à l'épreuve des balles pour fonctionner.

J'ai fini par le réparer comme ceci:

const subLocales = [
  'ar-tn',
  'ar-dz',
  'ar-kw',
  'ar-ma',
  'ar-sa',
  'ar-ly',
  'de-at',
  'de-ch',
  'en-sg',
  'en-au',
  'en-ca',
  'en-gb',
  'en-ie',
  'en-nz',
  'es-us',
  'es-do',
  'fr-ca',
  'fr-ch',
  'gom-latn',
  'hy-am',
  'pa-in',
  'pt-br',
  'sr-cyrl',
  'tl-ph',
  'tlh',
  'tet',
  'ms-my',
  'it-ch',
  'tzl',
  'tzm',
  'tzm-latn',
  'nl-be',
  'ug-cn',
  'uz-latn',
  'zh-cn',
  'zh-hk',
  'zh-tw'
];

let momentLocale = i18n.locale.toLowerCase();

if (!subLocales.includes(momentLocale)) {
  momentLocale = momentLocale.substring(0, 2);
}

moment.locale(momentLocale);

avec react native zh locale pour certaines raisons: /

Cela peut être dû au fait que zh et quelques autres paramètres régionaux sont formatés différemment pour différencier simplifié et traditionnel. Voir https://gist.github.com/jacobbubu/1836273

@ rajivshah3 en effet j'avais zh_Hant_HK qui ne fonctionnait pas avec la méthode tapz J'utilise maintenant votre méthode qui semble la meilleure façon de traiter ce problème aussi facilement que possible merci pour votre message 👍

Même problème, en mode production RN uniquement.

Cela semble bien fonctionner pour moi.

import 'moment/locale/fr';
import 'moment/locale/es';
import 'moment/locale/de';
import 'moment/locale/en-gb';
import 'moment/locale/es-us';

const toMomentLocale = locale => {
  let momentLocale = locale;
  momentLocale = momentLocale.replace('_', '-').toLowerCase();
  momentLocale = ['en-gb', 'en-us'].includes(locale)
    ? momentLocale
    : momentLocale.split('-')[0];
  return momentLocale;
};

Tant que les données sont importées (ou en ) et qu'elles respectent le cas, cela semble bien fonctionner pour nous

C'est vraiment ridicule. Supprimer la section -region du code de langue n'est pas une solution.

1) Vous perdez la spécificité régionale des paramètres régionaux.
2) Pire encore, cette méthode provoquera d'autres plantages. Le chinois ( zh ), par exemple, n'existe même pas dans les paramètres régionaux MomentJS. Seuls zh-cn , zh-hk et zh-tw sont définis. Donc, si vous utilisez le code ci-dessus pour supprimer des régions de la chaîne de paramètres régionaux, votre application plantera immédiatement sur la plupart des appareils chinois. Juste un maigre ~ 800 millions d'utilisateurs de smartphones.

Ma solution de contournement temporaire (et totalement batshit) pour React Native est la suivante:

const locale = 'zh-cn'; // or en-US etc
const languageCode = moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-'))); // now 'zh', 'en' etc. Thanks <strong i="14">@adesmet</strong> 
let momentJsLocale;
switch(languageCode.toLowerCase()) {
  case 'zh':
    // No 'zh' locale exists in MomentJS. App will crash in production if used.
    momentJsLocale = 'zh-cn';
    break;
  case 'pa':
    momentJsLocale = 'pa-in';
    break;
  case 'hy':
    momentJsLocale = 'hy-am';
    break;
  default:
    momentJsLocale = languageCode.toLowerCase();
}
moment.locale(momentJsLocale);

@adammcarth Salut, avons-nous des nouvelles de la correction des paramètres régionaux pour RN?

Cela vient de planter sur une version de version en ce moment en utilisant en-gb .

Je reçois un problème similaire à celui de; @simeyla .

Quand j'ai ajouté Luxon avec des problèmes de timepicker surgissent et ils semblent être liés à la locale «en-US».

@steveccable Eh bien, il essaie de le charger, juste au cas où vous auriez une localisation plus spécifique. Lorsqu'il échoue, il essaie simplement "en" et réussit. Je pense que la déconnexion est simplement que le fait de ne pas charger "en-US" se brise pour vous. Rien n'est censé exploser ici; _ il est juste censé échouer gracieusement_ et passer à l'option suivante. Vous devrez donc m'en dire plus sur votre environnement: qu'est-ce qui ne va pas précisément?

Un autre problème avec la gestion de 'en-US' ou d'autres locales valides avec des exceptions est que lorsque vous déboguez et demandez au débogueur de freiner les exceptions, vous restez bloqué sur celui-ci à plusieurs reprises.

Il devrait y avoir un moyen meilleur et plus simple, en particulier pour une locale aussi grande que «en-US».
Finalement, ces lieux avec possibilité de large public / utilisation devraient être vérifiés et traités en avant, pour une considération de vitesse.

J'ai modifié la solution de @slorber pour qu'elle soit plus robuste. Cela reformate une locale entrante (par exemple "zh_CN" en "zh-cn") et vérifie si elle est prise en charge par votre installation moment, revenant au pays, puis revenant à en-us.

const toMomentLocale = (locale) => {
  let newLocale = locale.replace('_', '-').toLowerCase();
  let tryLocales = [newLocale, newLocale.split('-')[0]];
  for (let i = 0; i < tryLocales.length; i++) {
    if (moment.locales().indexOf(tryLocales[i]) >= 0) return tryLocales[i];
  }
  return 'en-us';
};

// use it like this:
let m = moment();
m.locale(toMomentLocale('zh_CN')).format('LLL'); // "2019年12月11日上午9点33分" -- used "zh-cn"
moment.locale(toMomentLocale('ja_JP'));
moment().format('LLL') // 2019年12月11日 09:34 -- falls back to "ja"

Même problème, en mode IOS de production RN uniquement.

Cela semble bien fonctionner pour moi.

importer le moment à partir du «moment»;
import 'moment / locale / es';

J'ai passé un certain temps à déboguer ceci, merci @jorodriguez pour cela

C'est toujours un problème 😢

Salut les gars,

J'ai créé un petit paquet pour vous -> https://github.com/tonix-tuft/moment-utl

npm install --save moment moment-utl

Vous pouvez utiliser ce qui suit pour déterminer tous les paramètres régionaux pris en charge du moment sans avoir besoin de les charger à l'avance:

import { allSupportedLocales, allSupportedLocalesMap } from "moment-utl";

const locales = allSupportedLocales(); // As an array: ["af", "ar", "ar-dz", "ar-kw", "ar-ly", "ar-ma", "ar-sa", "ar-tn", "az", "be", "bg", ...,  "en", ..., "zh-tw"]

const localesMap = allSupportedLocalesMap(); // As an object: { "af": 1, "ar": 2, "ar-dz": 3, "ar-kw": 4, "ar-ly": 5, "ar-ma": 6, "ar-sa": 7, "ar-tn": 8, "az": 9, "be": 10, ..., "en": 27, "zh-tw": 128 };

moment-utl peer dépend de moment , mais il regroupe toutes les moment locales
les extraire du répertoire moment/locale lors de la construction d'un paquet de dépendances moment dev.

Cependant, comme moment est une dépendance de pair, si vous utilisez ES6 et que vous voulez vous assurer que allSupportedLocales et allSupportedLocalesMap utilisent tous les deux des paramètres régionaux à jour avec moment version que vous avez installée dans votre projet avec moment-utl (par exemple, si moment ajoute un jour une nouvelle locale, cela devrait vous couvrir), alors vous pouvez également régénérer ces locales en utilisant le moment-utl-locales script fourni par moment-utl .

Vous pouvez l'utiliser avec la commande npx :

npm install -g npx    # Install npx if you don't have it yet
npx moment-utl-locales    # Run this command from your project's root folder

Lorsque vous utilisez ce script, assurez-vous simplement de l'exécuter avant de regrouper votre code avec Rollup ou Webpack (selon ce que vous utilisez), afin qu'il génère un tableau et un objet de locales à jour avant que votre bundler ne les trouve et les ajoute à votre paquet final.

J'espère que ça aide!

En réponse à @adammcarth , veuillez vérifier ma réponse ici: https://github.com/tonix-tuft/moment-utl/issues/1#issuecomment -616088826

Ce problème a hanté les gars d'Odoo et le correctif suggéré était de créer le fichier en-us manuellement. Soupir.

Ce que je ne comprends pas, c'est pourquoi moment essaie de charger le fichier en-us si, comme indiqué dans certains commentaires ci-dessus, le chargeur doit savoir qu'il a déjà "en" et ne pas l'importer dynamiquement.

Quoi qu'il en soit, c'est toujours un cauchemar pour les utilisateurs RN. Le pire, c'est que le problème ne se produit que dans les versions de production.

Avoir un défaut caché est un paquet de surprises ...

Ce problème a hanté les gars d'Odoo et le correctif suggéré était de créer le fichier en-us manuellement. Soupir.

Ce que je ne comprends pas, c'est pourquoi moment essaie de charger le fichier en-us si, comme indiqué dans certains commentaires ci-dessus, le chargeur doit savoir qu'il a déjà "en" et ne pas l'importer dynamiquement.

Quoi qu'il en soit, c'est toujours un cauchemar pour les utilisateurs RN. Le pire, c'est que le problème ne se produit que dans les versions de production.

Avoir un défaut caché est un paquet de surprises ...

Je vais obtenir 👎 pour cela, mais ma solution était d'échanger moment contre dayjs . Comme ils partagent le même nom de fonction / API, c'était aussi simple qu'un find all + replace all pour moi.

Je ne fais que partager ce que j'ai fait pour les personnes qui pourraient vouloir y réfléchir.