feat(build): migrate from Prettier to Oxfmt for performant code formatting (#42434)

docs/developer_docs_versioned_docs/version-6.1.0/guidelines/design-guidelines.md

@@ -40,6 +40,7 @@ Sentence case is predominantly lowercase. Capitalize only the initial character
 - User input that is reflected in the UI. E.g. a user-named a dashboard tab
 
 **Sentence case vs. Title case:**
+
 - Title case: "A Dog Takes a Walk in Paris"
 - Sentence case: "A dog takes a walk in Paris"
 
@@ -110,12 +111,12 @@ Primary buttons have a fourth style: dropdown.
 
 **Purpose:**
 
-| Button Type | Description |
-|------------|-------------|
-| Primary | Main call to action, just 1 per page not including modals or main headers |
-| Secondary | Secondary actions, always in conjunction with a primary |
-| Tertiary | For less prominent actions; can be used in isolation or paired with a primary button |
-| Destructive | For actions that could have destructive effects on the user's data |
+| Button Type | Description                                                                          |
+| ----------- | ------------------------------------------------------------------------------------ |
+| Primary     | Main call to action, just 1 per page not including modals or main headers            |
+| Secondary   | Secondary actions, always in conjunction with a primary                              |
+| Tertiary    | For less prominent actions; can be used in isolation or paired with a primary button |
+| Destructive | For actions that could have destructive effects on the user's data                   |
 
 ### Format
 
@@ -173,9 +174,9 @@ In all cases, encountering errors increases user friction and frustration while
 
 Select one pattern per error (e.g. do not implement an inline and banner pattern for the same error).
 
-| When the error... | Use... |
-|------------------|--------|
-| Is directly related to a UI control | Inline error |
+| When the error...                       | Use...       |
+| --------------------------------------- | ------------ |
+| Is directly related to a UI control     | Inline error |
 | Is not directly related to a UI control | Banner error |
 
 #### Inline

docs/developer_docs_versioned_docs/version-6.1.0/guidelines/frontend-style-guidelines.md

@@ -43,7 +43,7 @@ This is a list of statements that describe how we do frontend development in Sup
 - We organize our repo so similar files live near each other, and tests are co-located with the files they test.
   - See: [SIP-61](https://github.com/apache/superset/issues/12098)
 - We prefer small, easily testable files and components.
-- We use OXC (oxlint) and Prettier to automatically fix lint errors and format the code.
+- We use OXC tooling, namely `oxlint` and `oxfmt`, to automatically fix lint errors and format the code.
   - We do not debate code formatting style in PRs, instead relying on automated tooling to enforce it.
   - If there's not a linting rule, we don't have a rule!
   - See: [Linting How-Tos](../contributing/howtos.md#typescript--javascript)

docs/developer_docs_versioned_docs/version-6.1.0/guidelines/frontend/component-style-guidelines.md

@@ -58,21 +58,25 @@ superset-frontend/src/components
 **Reference naming:** Use `PascalCase` for React components and `camelCase` for component instances
 
 **BAD:**
+
 ```jsx
 import mainNav from './MainNav';
 ```
 
 **GOOD:**
+
 ```jsx
 import MainNav from './MainNav';
 ```
 
 **BAD:**
+
 ```jsx
 const NavItem = <MainNav />;
 ```
 
 **GOOD:**
+
 ```jsx
 const navItem = <MainNav />;
 ```
@@ -80,11 +84,13 @@ const navItem = <MainNav />;
 **Component naming:** Use the file name as the component name
 
 **BAD:**
+
 ```jsx
 import MainNav from './MainNav/index';
 ```
 
 **GOOD:**
+
 ```jsx
 import MainNav from './MainNav';
 ```
@@ -92,11 +98,13 @@ import MainNav from './MainNav';
 **Props naming:** Do not use DOM related props for different purposes
 
 **BAD:**
+
 ```jsx
 <MainNav style="big" />
 ```
 
 **GOOD:**
+
 ```jsx
 <MainNav variant="big" />
 ```
@@ -104,23 +112,27 @@ import MainNav from './MainNav';
 **Importing dependencies:** Only import what you need
 
 **BAD:**
+
 ```jsx
-import * as React from "react";
+import * as React from 'react';
 ```
 
 **GOOD:**
+
 ```jsx
-import React, { useState } from "react";
+import React, { useState } from 'react';
 ```
 
 **Default VS named exports:** As recommended by [TypeScript](https://www.typescriptlang.org/docs/handbook/modules.html), "If a module's primary purpose is to house one specific export, then you should consider exporting it as a default export. This makes both importing and actually using the import a little easier". If you're exporting multiple objects, use named exports instead.
 
 _As a default export_
+
 ```jsx
 import MainNav from './MainNav';
 ```
 
 _As a named export_
+
 ```jsx
 import { MainNav, SecondaryNav } from './Navbars';
 ```
@@ -138,10 +150,10 @@ Validate all props with the correct types. This replaces the need for a run-time
 ```tsx
 type HeadingProps = {
   param: string;
-}
+};
 
 export default function Heading({ children }: HeadingProps) {
-  return <h2>{children}</h2>
+  return <h2>{children}</h2>;
 }
 ```
 
@@ -152,7 +164,8 @@ Use `type` for your component props and state. Use `interface` when you want to
 In order to improve the readability of your code and reduce assumptions, always add default values for non required props, when applicable, for example:
 
 ```tsx
-const applyDiscount = (price: number, discount = 0.05) => price * (1 - discount);
+const applyDiscount = (price: number, discount = 0.05) =>
+  price * (1 - discount);
 ```
 
 ## Functional components and Hooks

docs/developer_docs_versioned_docs/version-6.1.0/guidelines/frontend/emotion-styling-guidelines.md

@@ -60,21 +60,21 @@ const StatusThing = styled.div`
 export const InfoThing = styled(StatusThing)`
   background: blue;
   &::before {
-    content: "ℹ️";
+    content: 'ℹ️';
   }
 `;
 
 export const WarningThing = styled(StatusThing)`
   background: orange;
   &::before {
-    content: "⚠️";
+    content: '⚠️';
   }
 `;
 
 export const TerribleThing = styled(StatusThing)`
   background: red;
   &::before {
-    content: "🔥";
+    content: '🔥';
   }
 `;
 ```
@@ -138,14 +138,20 @@ function FakeGlobalNav(props) {
   const menuItemStyles = css`
     display: block;
     border-bottom: 1px solid cadetblue;
-    font-family: "Comic Sans", cursive;
+    font-family: 'Comic Sans', cursive;
   `;
 
   return (
     <Nav>
-      <a css={menuItemStyles} href="#">One link</a>
-      <Link css={menuItemStyles} to={url}>Another link</Link>
-      <div css={menuItemStyles} onClick={() => alert('clicked')}>Another link</div>
+      <a css={menuItemStyles} href="#">
+        One link
+      </a>
+      <Link css={menuItemStyles} to={url}>
+        Another link
+      </Link>
+      <div css={menuItemStyles} onClick={() => alert('clicked')}>
+        Another link
+      </div>
     </Nav>
   );
 }
@@ -158,21 +164,29 @@ function FakeGlobalNav(props) {
 By default the `css` prop uses the object syntax with JS style definitions, like so:
 
 ```jsx
-<div css={{
-  borderRadius: 10,
-  marginTop: 10,
-  backgroundColor: '#00FF00'
-}}>Howdy</div>
+<div
+  css={{
+    borderRadius: 10,
+    marginTop: 10,
+    backgroundColor: '#00FF00',
+  }}
+>
+  Howdy
+</div>
 ```
 
 But you can use the `css` interpolator as well to get away from icky JS styling syntax. Doesn't this look cleaner?
 
 ```jsx
-<div css={css`
-  border-radius: 10px;
-  margin-top: 10px;
-  background-color: #00FF00;
-`}>Howdy</div>
+<div
+  css={css`
+    border-radius: 10px;
+    margin-top: 10px;
+    background-color: #00ff00;
+  `}
+>
+  Howdy
+</div>
 ```
 
 You might say "whatever… I can read and write JS syntax just fine." Well, that's great. But… let's say you're migrating in some of our legacy LESS styles… now it's copy/paste! Or if you want to migrate to or from `styled` syntax… also copy/paste!
@@ -261,9 +275,7 @@ AntD uses a cool trick called compound components. For example, the `Menu` compo
 Let's say you want to override an AntD component called `Foo`, and have `Foo.Bar` display some custom CSS for the `Bar` compound component. You can do it effectively like so:
 
 ```jsx
-import {
-  Foo as AntdFoo,
-} from 'antd';
+import { Foo as AntdFoo } from 'antd';
 
 export const StyledBar = styled(AntdFoo.Bar)`
   border-radius: ${({ theme }) => theme.borderRadius}px;