[material-ui-icons] load-order problem with SSR and ES6 use of material-ui; needs ES variant?

material-ui-icons uses material-ui/SvgIcon, which uses material-ui/styles/withStyles, which creates a static generateClassNames, resetting the static rule counter.

In an app that is otherwise using ES6 material-ui, including material-ui/**es**/styles/withStyles, this results in the counter being reset. If that happens before any JssProvider is set up, all good. But if it happens afterward, as is likely with chunked production client code, it resets the rule counter late, resulting in className skewage in hydration of the SSR rendering.

A workaround in client code is to force early loading of material-ui/styles/withStyles in the browser, e.g., in TypeScript:

import {default as wrongWithStyles} from 'material-ui/styles/withStyles'
const _fooWrongStyles = wrongWithStyles

[dantman]

Here’s the code for lodash-es and @material-ui/es.

	// Force imports of packages like lodash to use the *-es package variant
	new webpack.NormalModuleReplacementPlugin(/^lodash(\/|$)/, resource => {
		resource.request = resource.request.replace(
			/^(@[^/+]+\/[^/+]+|[^/+]+)(\/.*)?$/,
			'$1-es/$2'
		);
	}),
	// Force imports of packages like @material-ui/core to use the /es versions
	new webpack.NormalModuleReplacementPlugin(
		/^@material-ui\/core(\/|$)/,
		resource => {
			resource.request = resource.request.replace(
				/^(@[^/+]+\/[^/+]+|[^/+]+)(?:\/es)?(\/.*)?$/,
				'$1/es$2'
			);
		}
	),

It already works with lodash-es, so IMHO an @material-ui/icons-es would probably work out fairly well.

[dantman]

The only path forward I can think of is publish a second package like @material-ui/icons-es. But following #10649 (comment), it only works if you don’t rely on third-party libraries using Material-UI.

I don’t think @material-ui/icons/es and @material-ui/icons-es are any different in that regard. I use the MUI es/ folder fine even with 3rd party libraries using a WebPack config to make everything use es/.