[charts][data-grid][pickers] Enforce top-level type imports

[Janpot]

Sets the consistent-type-imports autofix style to block style (separate-type-imports) and adds the secondary import/consistent-type-specifier-style rule (prefer-top-level) across charts, data-grid, and date-pickers, merged into one config block.

Together the two rules enforce top-level import type { Foo } and disallow inline import { type Foo }:

• @typescript-eslint/consistent-type-imports (fixStyle: 'separate-type-imports'): marks unmarked type-only imports as a top-level import type.
• import/consistent-type-specifier-style (prefer-top-level): moves any remaining inline type specifiers (import { type X }) up to a top-level import type.

The bulk of the diff is the autofix converting existing inline imports to block style across the three packages.

To review just the config change: d4aaa07

[code-infra-dashboard]

Deploy preview

https://deploy-preview-22679--material-ui-x.netlify.app/

Bundle size

Bundle	Parsed size	Gzip size
@mui/x-data-grid	0B(0.00%)	0B(0.00%)
@mui/x-data-grid-pro	0B(0.00%)	0B(0.00%)
@mui/x-data-grid-premium	0B(0.00%)	0B(0.00%)
@mui/x-charts	0B(0.00%)	0B(0.00%)
@mui/x-charts-pro	0B(0.00%)	0B(0.00%)
@mui/x-charts-premium	0B(0.00%)	0B(0.00%)
@mui/x-date-pickers	0B(0.00%)	0B(0.00%)
@mui/x-date-pickers-pro	0B(0.00%)	0B(0.00%)
@mui/x-tree-view	0B(0.00%)	0B(0.00%)
@mui/x-tree-view-pro	0B(0.00%)	0B(0.00%)
@mui/x-license	0B(0.00%)	0B(0.00%)

Details of bundle changes

Performance

Total duration: 1,974.19 ms +75.36 ms^(+4.0%) | Renders: 63 ⁽⁺⁰⁾

Test	Duration	Renders
SparkLineChart grid of 100 instances	181.07 ms 🔺+35.32 ms(+24.2%)	1 (+0)
ScatterChart with big data amount	30.92 ms 🔺+7.51 ms(+32.1%)	2 (+0)
RadialLineChart with big data amount	18.77 ms 🔺+5.17 ms(+38.0%)	2 (+0)
RadialBarChart stacked with multiple series	20.38 ms 🔺+4.42 ms(+27.7%)	2 (+0)
PieChart with big data amount	12.44 ms 🔺+3.94 ms(+46.3%)	2 (+0)

…and 1 more (+20 within noise) — details

Metric alarms

Test	Metric	Change
SparkLineChart grid of 100 instances	bench:paint	🔺 +65.45 ms
ScatterChart with big data amount	bench:paint	🔺 +13.63 ms
RadialLineChart with big data amount	bench:paint	🔺 +11.40 ms
RadialBarChart stacked with multiple series	bench:paint	🔺 +7.24 ms
PieChart with big data amount	bench:paint	🔺 +6.13 ms

---

Check out the code infra dashboard for more information about this PR.

[LukasTy]

LGTM. 👍

What's the plan with import type {} going forward?
Should we do a follow-up replacing those with inline imports?
Is there any benefit to inline imports, or are they equal in performance or other relevant metrics?

[Janpot]

What's the plan with import type {} going forward?

My personal preference would be to decide on a style and fix existing issues first, but the team didn't express interest.

[LukasTy]

but the team didn't express interest

Do you mean Code Infra or the X team?
FWIW, a "hyperoptimizer" in me would prefer dropping the import line completely for only type imports, but on the other hand, going for only inline type declarations will provide less diff churn. So, I'd be happy with it as well. 👌

[Janpot]

Do you mean Code Infra or the X team?

There was a discussion in https://mui-org.slack.com/archives/C011VC970AW/p1780421406363449

FWIW, a "hyperoptimizer" in me would prefer dropping the import line completely for only type imports, but on the other hand, going for only inline type declarations will provide less diff churn. So, I'd be happy with it as well. 👌

Yeah, either way is fine. If you prefer type imports and the rest of the team doesn't care then we simply do type imports. The trade-off of it is that we do two import statements instead of one, which is not a problem ofcourse, it purely comes down to preference. advantage is that it's also the default fixStyle

[LukasTy]

Do you mean Code Infra or the X team?

There was a discussion in https://mui-org.slack.com/archives/C011VC970AW/p1780421406363449

Gotcha.
Well, given that this is the same topic as tabs vs spaces, it's no surprise that the majority doesn't care too much. :)

Yeah, either way is fine. If you prefer type imports and the rest of the team doesn't care then we simply do type imports. The trade-off of it is that we do two import statements instead of one, which is not a problem ofcourse, it purely comes down to preference. advantage is that it's also the default fixStyle

If the change towards type imports is considerably smaller in scope, I'm on board. 😊

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[Janpot]

If the change towards type imports is considerably smaller in scope, I'm on board. 😊

  ┌───────────────┬──────────────────────────┬────────────────────────┬────────────────────┐
  │    Metric     │ Block (prefer-top-level) │ Inline (prefer-inline) │     Difference     │
  ├───────────────┼──────────────────────────┼────────────────────────┼────────────────────┤
  │ Files changed │                    1,368 │                  1,345 │                −23 │
  ├───────────────┼──────────────────────────┼────────────────────────┼────────────────────┤
  │ Insertions    │                   +5,290 │                 +5,175 │               −115 │
  ├───────────────┼──────────────────────────┼────────────────────────┼────────────────────┤
  │ Deletions     │                   −5,780 │                 −4,776 │             −1,004 │
  ├───────────────┼──────────────────────────┼────────────────────────┼────────────────────┤
  │ Total churn   │                   11,070 │                  9,951 │ −1,119 (~10% less) │
  └───────────────┴──────────────────────────┴────────────────────────┴────────────────────┘

Looks like the inline type imports cause about 10% fewer changes than separating them. But I wouldn't necessarily call that "considerably" smaller.