[l10n] Allow importing the direct locale file

[LukasTy]

Localization files are a perfect candidate for importing directly (2 levels deep in our case).
The majority of date libraries suggest doing it like this as well, i.e.:

• import 'dayjs/locale/fr';
• import 'moment/locale/fr;

In our case, the following is not possible: import { frFR } from '@mui/x-date-pickers/locales/frFR';.

Allowing the deeper import would:

• avoid the dev performance drawback of bundling all the locales.
• make the localization more in line with the approach used by date libraries
• potentially avoid the need to artificially limit the amount of locales we want to support (bundle)

Related issues: #10918, #10919, mui/material-ui#39525.

Search keywords:

[oliviertassinari]

Would it work with only?

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

Supporting 3rd levels import comes with a downside. Today, we set the expectation that all 2nd level imports are allowed and all 3rd levels are not. Introduction an exception to the rule could make it hard for developers to know when which one is OK.

Related to mui/material-ui#31096.

[LukasTy]

Would it work with only?

It would, but what about localization-related DX?
I think many people might already be used to localization usually being imported directly, however, your suggestion seems quite an unusual one. 🤔

Just confirming, that @flaviendelangle was specifically suggesting to introduce such importing exception only for locales, with a plan of possibly removing the locales/index and re-exporting on the next major, thus avoiding any problems with bundle bulking. 🤔
WDYT @oliviertassinari about such a plan?