feat(lint/useExportType): add rule

[Conaclos]

Summary

This rule implements some part of consistent-type-exports.
In contrast to the ESLint rule:

• we use export { type } by default. ESLint provides an option for this and split an export between a value export and a export type.

  For example, given the following code:

  interface I {}
  class C {}
  export { I, C }

  ESlint proposes the following fix:

  interface I {}
  class C {}
  export { C }
  export type { I }

  While this rules proposes the following fix:

  interface I {}
  class C {}
  export { type I, C }

• The ESLint rule is aware of which re-export name is a type. Biome has no information on re-exported names.

• ESLint doesn't factorize (group) an export that contains only type-only exports.

  For example, Biome proposes the following fix, while ESLint doesn't:

  - export { type X, type Y }
  + export type { X, Y }

Test Plan

Tests included.

[Conaclos]

See the ongoing discussion in rome#4751.

[github-actions]

Parser conformance results on

js/262

Test result	main count	This PR count	Difference
Total	49701	49701	0
Passed	48721	48721	0
Failed	980	980	0
Panics	0	0	0
Coverage	98.03%	98.03%	0.00%

jsx/babel

Test result	main count	This PR count	Difference
Total	40	40	0
Passed	37	37	0
Failed	3	3	0
Panics	0	0	0
Coverage	92.50%	92.50%	0.00%

symbols/microsoft

Test result	main count	This PR count	Difference
Total	6322	6322	0
Passed	2036	2036	0
Failed	4286	4286	0
Panics	0	0	0
Coverage	32.20%	32.20%	0.00%

ts/babel

Test result	main count	This PR count	Difference
Total	662	662	0
Passed	592	592	0
Failed	70	70	0
Panics	0	0	0
Coverage	89.43%	89.43%	0.00%

ts/microsoft

Test result	main count	This PR count	Difference
Total	17646	17646	0
Passed	13453	13453	0
Failed	4191	4191	0
Panics	2	2	0
Coverage	76.24%	76.24%	0.00%

[netlify]

✅ Deploy Preview for biomejs ready!

Name	Link
🔨 Latest commit	53d25fb
🔍 Latest deploy log	https://app.netlify.com/sites/biomejs/deploys/65720ac4fdeaa100084677ee
😎 Deploy Preview	https://deploy-preview-29--biomejs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ematipico]

Factorize export { type X, type Y } into export type { X, Y }

This is already done by https://biomejs.dev/linter/rules/use-grouped-type-import/ , do we need the fix in this rule too? Or, is there something I am missing?

[Conaclos]

Factorize export { type X, type Y } into export type { X, Y }

This is already done by https://biomejs.dev/linter/rules/use-grouped-type-import/ , do we need the fix in this rule too? Or, is there something I am missing?

useGroupedTypeImport factorize import { type } to import type {}. It doesn't factorize export { type }.

We discussed it in the corresponding rome issue.
To summarize:

We could implement two rules and deprecate useGroupedTypeImport:

• useExportType that enforces the use of export type and export { type } and factorizes the latter into the former.
• useImportType that enforces the use of import type and import { type } and factorizes the latter into the former.

Alternatively, we could perform the factorization of import { type } and export { type } with organizeImports. In this case, useImportType and useExportType could produce unfactorized code.

I am a bit shared about which approach to choose. We could even adopt both.

[ematipico]

Sorry I made a mistake, thank you for clarifying.

I asked because today my team needed consistent-type-imports and I misread things.

Is there an issue to track useImportType?

[Conaclos]

Is there an issue to track useImportType?

No, once this PR merged, I will start working on.

Have you any thoughts about which approach to use?

[ematipico]

Is there an issue to track useImportType?

No, once this PR merged, I will start working on.

Have you any thoughts about which approach to use?

I think the best course of action is to use a lint rule, mainly because there's a reason if TypeScript decided to do this:

import {type something} from "something.js"

import {} from "something.js";

Hence, if there's a case where users need to have this case enabled, they should be free to turn it off using a suppression comment.

[Conaclos]

Is there an issue to track useImportType?

No, once this PR merged, I will start working on.
Have you any thoughts about which approach to use?

I think the best course of action is to use a lint rule, mainly because there's a reason if TypeScript decided to do this:

import {type something} from "something.js"

import {} from "something.js";

Hence, if there's a case where users need to have this case enabled, they should be free to turn it off using a suppression comment.

I think this doesn't hold for exports. Thus, I decided to factorize type-only exports when possible. Ready for review.

[ematipico]

Can a bundler really three shake this? Or can typescript really do that?

[Conaclos]

I think so. Since the export is declared as a type, the bundler/compiler knows that the entity is not used a runtime. Thus, it can remove this specific export. Otherwise, it has to check if the definition is a type. Many bundlers, such as ESbuil assume that you use the isolated module mode because they are not able to do multi-file analysis. Thus, they are not able to understand when an imported value is only a type. Requiring type-only exports and imports help them to detect types and runtime values.

[ematipico]

Let's 🚢 it, people want it!