feat(noExportedImports): add lint rule

[Conaclos]

Summary

Add a new exclusive rule for Biome.
The rule disallows exporting an imported variable and suggests using export from.
This is an implementation I had done some time ago. I had intended to add a code fix before submitting a PR.
However, I now think that the rule is ok without a code ix.

Test Plan

I added some tests.

[github-actions]

Parser conformance results on

js/262

Test result	main count	This PR count	Difference
Total	50227	50227	0
Passed	49120	49120	0
Failed	1107	1107	0
Panics	0	0	0
Coverage	97.80%	97.80%	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	6534	6534	0
Passed	2084	2084	0
Failed	4450	4450	0
Panics	0	0	0
Coverage	31.89%	31.89%	0.00%

ts/babel

Test result	main count	This PR count	Difference
Total	669	669	0
Passed	597	597	0
Failed	72	72	0
Panics	0	0	0
Coverage	89.24%	89.24%	0.00%

ts/microsoft

Test result	main count	This PR count	Difference
Total	18244	18244	0
Passed	13981	13981	0
Failed	4263	4263	0
Panics	0	0	0
Coverage	76.63%	76.63%	0.00%

[codspeed-hq]

CodSpeed Performance Report

Merging #3097 will not alter performance

_{Comparing conaclos/noExportedImports (413e850) with main (b3d8bfd)}

Summary

✅ 90 untouched benchmarks

[ah-yu]

Looks good!

[Sec-ant]

I have some use cases like this:

import { A } from "mod";
// do something with A
export { A };

Does this rule allow it? What if I mutate A and export it, should I use an alias?

[ematipico]

Would this rule go in conflict with the barrel file rule?

[ematipico]

Nit:

Based on our rule pillars, we usually do: error, explain the error, suggest a fix

You should swap the notes

[Conaclos]

Swap the notes?

The first diagnostic is the error and the suggestion. The second is the explanation.

In an IDE settings it is sometimes confusing to only have the error without any suggestion or explanation.

[Conaclos]

Would this rule go in conflict with the barrel file rule?

I don't think so.
The only thing that can happen is to suggest using export from and the nonce changed this can be reported by the noReexport rule. And this is good because re-exporting an import is a re-export.

[Conaclos]

I have some use cases like this:

import { A } from "mod";
// do something with A
export { A };

Does this rule allow it? What if I mutate A and export it, should I use an alias?

Have you a more precise example?
Usually imports are considered immutable?

[Sec-ant]

Have you a more precise example?
Usually imports are considered immutable?

I was thinking something like this:

a.js:

export const user = {
	name: undefined,
};

b.js:

import { user } from "./a.js";

user.name = "John";

export { user };

index.js:

import { user } from "./b.js";

console.log(user);

But it seems I can use export { user } from "./a.js" in b.js without any issue. So I think I have no more questions.

[Conaclos]

@Sec-ant

Yes you can write:

import { user } from "./a.js";
user.name = "John";

export { user } from "./a.js";

[ematipico]

Would this rule go in conflict with the barrel file rule?

I don't think so.
The only thing that can happen is to suggest using export from and the nonce changed this can be reported by the noReexport rule. And this is good because re-exporting an import is a re-export.

Sorry I didn't understand very well. I understood that the suggested fix could trigger noReexport?

[Conaclos]

Sorry I didn't understand very well. I understood that the suggested fix could trigger noReexport?

Yes, this is expected.