[l10n] Stop re-exporting locales from package root

[LukasTy]

We currently re-export locales from in the root index file so that they are available from both import { frFR } from '@mui/x-date-pickers/locales' and import { frFR } from '@mui/x-date-pickers'.

mui-x/packages/x-date-pickers/src/index.ts

Line 8 in 947619d

export * from './locales';

We should avoid root-level exporting as it doesn't solve any particular problem besides making the package seem bulkier.

-import { frFR } from '@mui/x-date-pickers';
+import { frFR } from '@mui/x-date-pickers/locales';

Search keywords:

Why?

It's for marketing reasons (meaning perceived value, which is not the same as real value). See in mui/material-ui#39525

As for the bundle size, IMHO, even removing the top-level export (export * from './locales') would help a lot.
Currently, every new locale artificially inflates the bundle size of our package. Having a big bundle size is definitely not a positive sign in the ecosystem.

[flaviendelangle]

I'm wondering if it's worth doing this before we provide an actual good solution to avoid bundling all locales in anyone bundle (in dev).

With this change, people using the default locale won't bundle the locales in dev mode,
But since we probably want to provide a solution to import individual locale (with imports like @mui/x-date-pickers/fr-FR-locale or @mui/x-date-pickers/locales/fr-FR), people will have to migrate twice to eventually have the good approach:

Today: @mui/x-date-pickers
Tomorrow: @mui/x-date-pickers/locales
In a few months (?): @mui/x-date-pickers/locales/fr-FR (non-definitive API)

Would it be better for our community to release the new endpoint before removing the root export?
That way people could migrate from @mui/x-date-pickers to the final endpoint in one go.

I know that @mui/x-date-pickers/locales will remain available, but it probably won't be the recommended approach (just like root import exist for all components but we don't recommend it).

One could even wonder if removing it is useful, since people can import everything without ever using the root import.
I'd be curious to see the bundle size in dev of someone using the root import if it includes locales and if it does not.
But I don't have a strong opinion on that one, my main point in this message is the timing.

[LukasTy]

@flaviendelangle I'm not sure we need to move towards allowing only direct locale imports.
It does not seem that the date-fns library would stress about it.
They allow locales root importing - import { de } from "date-fns/locale";.

The main benefit that they reap and we want to benefit as well is the de-inflation of the bundle size.

As @oliviertassinari noted, he would not be in favor of adding an exception allowing 3rd-level importing only for locales.
If we take that into account and consider that imports would have to be something like:
import { fr } from '@mui/x-date-pickers/locale-fr'.
I'm not sure if DX is better than:
import { fr } from '@mui/x-date-pickers/locales/fr'... 🤔 🤷

[flaviendelangle]

As @oliviertassinari noted, he would not be in favor of adding an exception allowing 3rd-level importing only for locales.

We have a broader topic here that I briefly discussed with @oliviertassinari a few weeks ago.
When we will add Joy and unstyled versions of our components, one of the proposed DX is to have the following:

import { DatePicker } from '@mui/x-date-picker/joy'
import { DatePicker } from '@mui/x-date-picker/material'
import { DatePicker } from '@mui/x-date-picker/base'

But once we have that, do we drop the support for nested imports or do we allow the following:

import { DatePicker } from '@mui/x-date-picker/joy/DatePicker'

If we drop the support for nested imports, then for me it's coherent to also not support it for the locales and only have @mui/x-date-pickers/locales'

But if we want to support it, then we end up in a situation with only a few folders in the package and imports of depth 3 allowed.

For me both make sense and both end up with consistent results which is the most important outcome here.
The main difference between the two is tree-shaking in dev and it's unclear how important it is (both from a pure performance point of view and from a community appreciation point of view).

[oliviertassinari]

But once we have that, do we drop the support for nested imports or do we allow the following:

import { DatePicker } from '@mui/x-date-picker/joy/DatePicker'

It might be OK. It's a relatively small package: https://bundlephobia.com/package/@mui/x-date-pickers@6.19.0. I imagine that once we remove the locales, from the entry point, it will be even smaller.

with consistent results

For me, the main problem is to educate users about what's a private module and what's a public one. Today private is deep import with depth >= 3, very simple.

If we can get the same outcome with exports, then why not:

https://nodejs.org/api/packages.html#exports

[oliviertassinari]

I have added a Why section to this issue description. We are not doing this change for technical reasons but for marketing ones.

It's about not being at a disadvantage for developers who don't understand tree-shaking and comparing us to other libraries. Technically, bundle size stays the same, developers who care about build speed (and are not on Next.js) can continue to import modules one level deep. The only price we have to pay is a small surprise to not being able to import from the top level.

We are using the same tradeoff with Material UI, proof, https://bundlephobia.com/package/@mui/material@5.15.6. So it's also more consistent MUI-wise.