Hacker News new | ask | show | jobs
by yodon 2376 days ago
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.

1 comments

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.