[code-infra] Move MuiError babel macro to babel plugin

[Janpot]

This plugin replaces code of the form

throw /* minify-error */ new Error(`MUI: invalid ${foo} on ${bar}`);

with

import _formatMuiErrorMessage from '@mui/utils/formatMuiErrorMessage'

// ...

throw new Error(process.env.NODE_ENV !== "production" ? `MUI: invalid ${foo} on ${bar}` : _formatMuiErrorMessage(1, foo, bar));

It replaces the former

import MuiError from '@mui/internal-babel-macros/MuiError.macro';

// ...

throw new MuiError(`MUI: invalid %s on %s`, foo, bar);

Same functionality in terms of error extraction as the MuiError babel macro, but the code is still runnable without the babel-plugin-macros plugin (just with unminified errors).

Also moved the check that guards against calling Error(...) without new to eslint
Also refactored the formatMuiErrorMessage as it looks like the optimizations don't make sense anymore, babel doesn't transform them anymore. Looks like it shaved off 16B 😄

Initially minified every error instance, which resulted in the following bundle sizes:

@material-ui/unstyled: parsed: -0.19% 😍, gzip: -0.22% 😍
@mui/joy: parsed: -0.06% 😍, gzip: -0.09% 😍
Transitions: parsed: +9.38% , gzip: +13.36%
Dropdown: parsed: +6.78% , gzip: +9.52%
@mui/joy/Dropdown: parsed: +6.79% , gzip: +9.52%
Tabs: parsed: +2.90% , gzip: +4.69%
MenuButton: parsed: +2.51% , gzip: +4.26%

---

@mui/code-infra What are your thoughts. I don't want to refactor the whole setup, the main goal is to remove babel-macros, but I'm on the fence on what to use as a marker for deciding which errors to minify. Alternatives to consider:

• Tagged template literal exported from '@mui/internal-babel-plugin-minify-error'

  import minifyError from '@mui/internal-babel-plugin-minify-error';
  
  // ...
  
  throw new Error(minifyError`MUI: invalid ${foo} on ${bar}`)

  • pro:
    • Forces one way of doing things
    • agnostic of the Error constructor, can assign them to a variable and share with multiple Errors, e.g.
      

      material-ui/docs/src/modules/components/ApiPage/definitions/classes.ts

      Lines 45 to 46 in 5cee5bd

      	const errorMessage = (componentName: string, className: string, slotName: string): string =>
      	`${className} description from component ${componentName} should include ${slotName} since its definition includes "{{${slotName}}}"`;

  • con:
    • can't compose them easily like we can with regular string literals. e.g. to spread them across multiple lines.

• Just minify every error of the pattern new Error(MUI: invalid ${foo} on ${bar})

  • Pro:
    • Forces usage, programmer doesn't need to be aware
  • cons:
    • Seems to affect bundle size a lot, but this may be a false positive, chances are quite high formatMuiErrorMessage will be included one way or the other. The individual bundle size may give a wring impression.

---

Main advantage of the /* minify-error */ is the fact that it doesn't require an import. The code is exactly the code that would execute when unminified. This makes the plugin a pure optimization.

[mui-bot]

Netlify deploy preview

https://deploy-preview-43904--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against f49eba0

[Janpot]

@michaldudak I renamed to just minify-error