[Tabs] Alternative way to disable ":first-child is unsafe" error

[hbjORbj]

• I have followed (at least) the PR section of the contributing guide.

This PR introduces 2 alternatives to disable the ":first-child is unsafe" error:

• Source of error:

...(ownerState.icon &&
    ownerState.label && {
      ...,
      [`& > *:first-child`]: {
        marginBottom: 6,
      },
    }),

• [Tabs] Fix ":first-child is potentially unsafe" error #28890 was the first iteration. Its solution was wrapping icon with a span with a classname and target the classname for styling:

@@ -176,7 +183,8 @@ const Tab = React.forwardRef(function Tab(inProps, ref) {
       tabIndex={selected ? 0 : -1}
       {...other}
     >
-      {icon}
+      {icon && <span className={classes.icon}>{icon}</span>}

Since the first iteration changes the DOM rendered, I prepared two alternatives:
(1) Use '/* emotion-disable-server-rendering-unsafe-selector-warning-please-do-not-use-this-the-warning-exists-for-a-reason */'

• Reference: https://github.com/emotion-js/emotion/blob/main/packages/react/__tests__/warnings.js#L87

@@ -59,8 +62,10 @@ const TabRoot = styled(ButtonBase, {
        ...,
-      [`& > *:first-child`]: {
-        marginBottom: 6,
+      [`& > *`]: {
+        [`:first-child ${ignoreSsrFlag}`]: {
+          marginBottom: 6,
+        },
       },
     }),

• most concise solution but not supporting zero SSR configuration might not be a good idea

(2) Clone icon with a classname and target the classname for styling:

@@ -148,7 +148,12 @@ const Tab = React.forwardRef(function Tab(inProps, ref) {
   };
 
   const classes = useUtilityClasses(ownerState);
-
+  const icon =
+    iconProp && label && typeof iconProp !== 'string'
+      ? React.cloneElement(iconProp, {
+          className: classes.iconWrapper,
+        })
+      : iconProp;

• code sandbox: https://codesandbox.io/s/ecstatic-mendel-i8c43?file=/src/App.js

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against f4f5d05

[eps1lon]

Changed tests are usually an indicator that a change is breaking existing behaivor. Either make the tests purely additive, explain why this is a bugfix not a feature or delay until v6

[mnajdova]

Changed tests are usually an indicator that a change is breaking existing behaivor. Either make the tests purely additive, explain why this is a bugfix not a feature or delay until v6

@eps1lon the tests changes are coming from #28890 This PR is summarizing the alternatives proposed on that PR after it was merged. I guess this is why some tests need to be adjusted (it is the tests added in the mentioned PR, not something that was implemented before).

[hbjORbj]

Changed tests are usually an indicator that a change is breaking existing behaivor. Either make the tests purely additive, explain why this is a bugfix not a feature or delay until v6

@eps1lon Sorry for confusion. The tests modified in this PR hadn't existed prior to #28890 (the first iteration to address this bug). So, the tests can be considered purely additive.