Hi @earnest flame. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
#Turborepo export and import files
reef reefBOT
Based on the information provided in the extracts, it seems that you are using a Turborepo setup with Next.js. In this setup, you have a packages directory where you are exporting various components and layouts from an index.ts file. Then, in your apps directory, you are importing specific components from the shared-ui package.
In theory, when you import specific components like Header, Sidebar, and DefaultLayout from the shared-ui package, only the code for these components should be included in your bundle. This is a concept known as "tree shaking", which is a dead-code elimination technique used in modern module bundlers like Webpack.
However, there are some issues reported on Github (issue 55943 (https://github.com/vercel/next.js/issues/55943)) where users have experienced problems with tree shaking in a Turborepo setup with Next.js. Some users reported that even with "ordinary-non-barrel" exports, tree shaking was not working as expected and unused code was still included in the bundle.
Therefore, while the expected behavior is that only the components you import should be loaded, there may be some issues with tree shaking in this specific setup. You may want to check your bundle to ensure that only the necessary code is included.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
earnest flame
Is it better to create a separate package.json and index.ts for components and layouts?
Cause if we add more folders to it like hooks, api, contexts, types etc… we would just export it to the shared > ui > index.ts which might be bad?
What is your suggestion? @reef reef
reef reefBOT
Let me check the knowledge base for you. One moment! :books:
Based on the information provided in the extracts, it's not explicitly stated whether it's better to create separate package.json and index.ts files for components and layouts. However, it's important to note that the structure of your project largely depends on its scale, complexity, and the preferences of your development team.
In general, having a single index.ts file where you export everything from your shared-ui package can be convenient as it provides a single entry point to all shared UI elements. However, as you pointed out, as your project grows and you add more folders like hooks, API, contexts, types, etc., this file can become quite large and potentially harder to manage.
One approach to mitigate this could be to have separate index.ts files for each sub-directory (components, layouts, hooks, etc.) and then re-export everything from the main index.ts file in the shared-ui package. This way, you still have a single entry point, but the exports are organized in a more modular way.
As for the package.json, it's common to have a single package.json file per package in a monorepo setup. This file includes metadata about the package and its dependencies. If components and layouts are part of the same shared-ui package, they would typically share the same package.json file.
Remember, these are just general suggestions and the best structure for your project may vary based on your specific needs and circumstances. It's always a good idea to continuously evaluate your project structure as your codebase grows and refactor as necessary to keep things maintainable.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
earnest flame
@reef reef
pls give an example. probably using some of my codes abobe
reef reefBOT
Let me check the knowledge base for you. One moment! :books:
Sure, here's an example of how you could structure your exports with separate index.ts files for each sub-directory:
packages > shared > ui > components > index.ts
export * from "./Button";
export * from "./Card";
export * from "./Footer";
export * from "./Header";
export * from "./Sidebar";
packages > shared > ui > layouts > index.ts
export * from "./AuthLayout";
export * from "./DefaultLayout";
Then, in your main index.ts file for the shared-ui package, you would re-export everything from these sub-directories:
packages > shared > ui > index.ts
import "./tailwind.css";
// components
export * from "./components";
// layouts
export * from "./layouts";
This way, you still have a single entry point to your shared-ui package, but the exports are organized in a more modular way. You can apply the same pattern to other sub-directories as your project grows.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
earnest flame
@reef reef how about if you have hooks, context, constants, assets? same thing?
reef reefBOT
Let me check the knowledge base for you. One moment! :books:
Yes, the same pattern can be applied to other sub-directories such as hooks, context, constants, and assets. Here's how you could do it:
packages > shared > ui > hooks > index.ts
export * from "./useCustomHook1";
export * from "./useCustomHook2";
// ... other hooks
packages > shared > ui > context > index.ts
export * from "./MyContext";
// ... other contexts
packages > shared > ui > constants > index.ts
export * from "./constants";
// ... other constants
packages > shared > ui > assets > index.ts
export * from "./logo";
export * from "./icons";
// ... other assets
Then, in your main index.ts file for the shared-ui package, you would re-export everything from these sub-directories:
packages > shared > ui > index.ts
import "./tailwind.css";
// components
export * from "./components";
// layouts
export * from "./layouts";
// hooks
export * from "./hooks";
// context
export * from "./context";
// constants
export * from "./constants";
// assets
export * from "./assets";