Rule proposal: no-export-named-after-filename

[edbrannin]

Similar ideas have been floated in #1041 and #325, but this is a bit different:

If you have a Default export, don't also have a Named export that's named the same as the file.

This is to flag a possible root cause of import/no-named-as-default.

Bad:

// Foo.jsx
import React from 'react'
import myHOC from './my-hoc'

const Foo = () => <p>Foo</p>

export default myHOC(Foo)
export { Foo } // For testing

Good:

// Foo.jsx
import React from 'react'
import myHOC from './my-hoc'

const FooComponent = () => <p>Foo</p>

export default myHOC(Foo)
export { FooComponent } // For testing

Also good:

// FooComponent.jsx
import React from 'react'

const FooComponent = () => <p>Foo</p>

export default FooComponent // OR export { FooComponent }

// Foo.jsx
import React from 'react'
import FooComponent from './FooComponent'
import myHOC from './my-hoc'

export default myHOC(Foo)

Thoughts?

[ljharb]

Perhaps #1476 should also include an option that controls checking imports, exports, or both, and this issue’s suggestion could be the “exports” part? cc @golopot

[golopot]

Another similar rule proposal is export-default-match-filename, mentioned here,
which reports cases like:

// foo.js
export default function bar() {}
//                      ~~~  should match filename "foo.js"

I am not sure whether they should be separate rules, or all rolled into one.

[ljharb]

Having it rolled into one means the matching logic can be more centralized, both conceptually and technically.

[golopot]

I find it hard to name rule name and options when these are rolled into one. An attempt:

{
  "default-name-match-filename": [2, {
    importDefaultName: true | {ignorePaths: string[]},
    exportDefaultName: true,
    noExportNameAfterFilename: true,
  }]
}