A very simple change still preserves the "multiple compiled-data chunks at once" feature and fixes the regression.
Details
Problem details
On production, globalize imports [1] are transformed into corresponding precompiled formatters and parsers imports. After allow multiple compiled-data chunks at once, the transformation becames constrained to the default locale [2].
1: app.js (source)
import Globalize from "globalize";
2: app.js (production bundle)
import Globalize from `${precompiledFormattersAndParsersForLocaleX}`;
// Named example:
// Globalize = __webpack_require__( "./.tmp-globalize-webpack/-globalize-webpack-plugin-test-fixtures-app-js-en.js" );
Note: The precompiled bundle imports needed globalize runtime modules, includes minimal/optimized i18n data, and exports "globalize/dist/globalize-runtime".
In order to use a different locale (other than the default - usually English) you need to load a different locale in addition to default locale.
Solution details
The fix consists on simply not transforming globalize runtime imports, i.e., the globalize imports [1] are transformed into globalize runtime imports [2] and stays like that. The precompiled formatters and parsers are still extracted and generated the same way.
1: app.js (source)
import Globalize from "globalize";
2: app.js (production bundle)
import Globalize from "globalize/dist/globalize-runtime";
// Named example:
// const Globalize = __webpack_require__( "./node_modules/globalize/dist/globalize-runtime.js" );
Nothing changes in the way we use/load the bundles, i.e.:
Problem
After allow multiple compiled-data chunks at once, it's hard to use the compiled i18n bundles. Please, see problem details below.
Solution
A very simple change still preserves the "multiple compiled-data chunks at once" feature and fixes the regression.
Details
Problem details
On production, globalize imports [1] are transformed into corresponding precompiled formatters and parsers imports. After allow multiple compiled-data chunks at once, the transformation becames constrained to the default locale [2].
1: app.js (source)
2: app.js (production bundle)
Note: The precompiled bundle imports needed globalize runtime modules, includes minimal/optimized i18n data, and exports "globalize/dist/globalize-runtime".
In order to use a different locale (other than the default - usually English) you need to load a different locale in addition to default locale.
Solution details
The fix consists on simply not transforming globalize runtime imports, i.e., the globalize imports [1] are transformed into globalize runtime imports [2] and stays like that. The precompiled formatters and parsers are still extracted and generated the same way.
1: app.js (source)
2: app.js (production bundle)
Nothing changes in the way we use/load the bundles, i.e.:
vendors.js
i18n/<locale.js>
app.js