-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Use export * in component indexes #2619
Comments
👋 Thanks for opening your first issue. A contributor should give feedback soon. If you haven’t already, please check out the contributing guidelines. |
Pinging @chloerice, @AndrewMusgrave, @danrosenthal, @tmlayton, @alex-page, @kyledurand and @amrocha to get their thoughts on this. |
This is how I export in TS side projects. I'm by no means someone to advise you in the area of builds, but what you outlined makes sense to me. |
Thanks for spending time during our pairing to walk me through this. I'm in favor of the proposed change |
Super excited about the type only imports 😍 This all makes sense to me. As long as we're following the |
I like the general If yes then I'm all for it |
No linting rule from what I can see in eslint-plugin-import, but we can enable |
This makes a bunch of sense to me 👍 |
One concept I missed the first time around: What should we do with subcomponent indexes (e.g. |
+1 doing * exports from both component and subcomponent indexes |
A bit of a follow on from #1959
I've been looking at the feasibility of updating our build. Currently we do a complicated dance where we compile using typescript, then transpile that using babel. I've been investigating if instead we could just have babel read our TS files directly, which ends up being a fair bit simpler, however we need to modify our code slightly so Babel can handle type reexports correctly.
We've had this problem for a while - our Storybook build also uses babel to transform our TS files - however we've been able to ignore/suppress the generated warnings till now.
The issue is that we have errors when we reexport types. e.g.
When compiling with
tsc
it looks over the whole project and it knows thatActionListProps
is a type and thus should be removed from the compiled output. However babel only looks at a single file at a time so it doesn't know if ActionListProps is a type or value, so it assumes it is a value and leaves the export in. This however causes an issue in bundlers because when webpack/rollup processes this file it tries to find ActionListProps and then fails because it doesn't exist (as it is a type not a value). In webpack this results in thoseexport ActionListProps was not found in...
warnings, and is a hard error in rollup. Thus we need a way to stop these errors.I would like to propose changing how we export in component indexes, so that we can give babel the information it needs to properly remove type imports.
TypeScript 3.8 will introduce type-only imports/exports (final release expected in mid February), which is new syntax that will give babel the information to remove the type exports. So we could rewrite the ActionList index as:
However I feel this repetition is a somewhat annoying. Instead I think we should use star exports, to export everything from the
ActionList.ts
file. This sidesteps the issue entirely as bundlers will take whatever is there instead of us having to repeat the names of components and their props:This feels safe to me as the majority of the time components only export themselves and their props. There may be some cases where we would want to tweak the file layout slightly to ensure exports that are only used within a component are not exposed outside the component but those cases are in the small minority.
This will fix the majority of webpack/rollup's complaints today, however there are two other cases that the above does not address:
The rexporting of all components in
src/components/index.ts
should move to use theexport type
notation and make two export calls - this duplication is a little meh but it allows us to strongly control what gets exported from library instead of a blanket export - this helps protect us against accidentally exposing values that should be internal.The reexporting of types in our utilities e.g.
export {Theme, ThemeConfig, CustomPropertiesLike, ColorScheme} from './types';
insrc/utilities/theme/index.ts
. In these cases we should also use theexport type
notation too as there would be no values in that type file, so no repeated reexports.Does this seem like a reasonable proposal? Do you have any concerns?
If not I'll spin up a PR to make the changes to component indexes this/next week.
The text was updated successfully, but these errors were encountered: