[skidding]

I generally avoid defaults exports as well but didn't realize some codebases disable them completely. What do you mean by "non-default-exporting" TSX files, can you provide a link?

> Perhaps adding shim files that import the component and re-export as default?

Definitely, you could add a transform to the Cosmos build pipeline that renames some named export to default. If you're willing to write the transform I'll gladly help you integrate it.

[yodon]

In general each export is named with what it is, so SearchWidget.tsx, which contains a search widget, would explicitly "export { SearchWidget }".

Both tslint and eslint support no-default-export rules, so its clearly at least a semi common approach.

I can't speak to why others use the pattern but I can say enabling no-default-export gets rid of the "do I import * as foo from, import foo from, or import { foo } from" conundrum and enables the linter or transpiler to detect when there is code that accidentally tries to import Football from "baseball" because import { Football } from "baseball" (when baseball.tsx doesn't export Football) generates a clearer and more targeted error message than some noise message about invalid props or wrong number of children under <Football> because it picked up some bogus default export from baseball.tsx. (Definitely not trying to start a language war here, engineering is always about trade offs, and different people and projects make them differently without invalidating each other's choices.)

I'm guessing there is a way to make a generic transformer but it's not a type of TypeScript language fu I've messed with.

[skidding]

Totally agree, like I said I also avoid defaults exports (for the same reasons). But I'm fine with default exports in fixtures because you never import them by hand, they are picked up automatically by React Cosmos. And you can customize no-default-export rules to ignore fixture files.