Rule proposal: `no-barrel-files` or `no-re-export`

### Description In general, importing and re-exporting a value only *adds* a way to import it since the original export remains accessible. On this basis, `export-from` should never be used on files that share the same visibility. The `exports` field in package.json is what changes the "visibility". ### Examples ```js // ❌ export {value} from './file.js' // ❌ import {value} from './file.js' export {value} // ✅ import directly from the original file *where needed* import {value} from './file.js' ``` ### Proposed rule name no-re-export ### Additional Info To keep things simpler (without having to determine the "visibility" of any given file) and to follow the core principle, the rule could be implemented *regardless* of visibility, even if this means pushing libraries away from barrel files altogether. ```js // ❌ export {JsonValue} from './JsonValue.js' // ✅ import directly from the original file *where needed* import {JsonValue} from 'type-fest/json-value' ``` `type-fest` would actually be greatly affected by this, both because it would turn one import into many and because TS will no longer need to parse *the entire library* when you import a single type. This article contains more details: https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/