Questions: Barrel files and React memo

[maxstue]

Hello,

lately, inside a larger project, I tried switching from the other vite-react-plugin over to this one.
In that project I currently try to improve some things a bit and started implementing barrel files.

They seem to work with the other react-vite-plugin but if I switch to this one and make the same changes (just a tailwindcss change or add a simple div) the whole app gets reloaded.
My barrel files look similar to the following examples:

I added file endings for easier identification
Example 1:

// folder A
export * from './File1.tsx' // only one named export 'File1'
export * from './File2.tsx' // only one named export 'File2'
export * from './File3.tsx' // only one named export 'File3'

Example 2:

// folder B
export * from './File4.tsx' // only one named export 'File4'
export * from './File5.tsx' // only one named export 'File5'
export * from './use-get-hook.tsx' // only one named export 'useGetHook'
export * from './utilHelpers.tsx' // multiple named export 'hlper1, helper2'

The files inside a folder with a barrel file directly import the needed file and don't use the barrel file to prevent circular dependency.

Am I doing something wrong?
In some occasions even the other react-vite-plugin does a full reload, at that point I think I still have a mistake somewhere.

My second question is dependent on the eslint plugin that gets mentioned in the README.
As soon as I enable the eslint plugin
it says that the following code is not correct and might not work with fast-refresh. So my question is if I use React.memo wrong ?

// filename = Comp.tsx
function Comp() {
  return (<> ... </>)
}
export default memo(Comp);

I know my questions are not directly tight to this repo but it would be really helpful if someone helps me. :)

[ArnaudBarre]

On the barrels import side, difficult to know the issue without a repro. What I can tell you is that I stopped doing barrels imports when switching to Vite, it does very bad with the way Vite does HMR. One because it's very easy to do circular dependencies that triggers full reload, and two because each files look has a lot more dependency that the reality that causes a lot more invalidation that was is needed in reality. For ex, if A, B & C import folder D that export component E and util f, changing f invalidate A, B and C even if it's used only in B (not sure that clear with all these letters.). Happy to help with a repro, but I would advice to stop barrels anyway for faster HMR perf.

For the memo/eslint plugin I'm not sure if it's a real issue or not. In practice I never use default export (expect for this plugin for compatibility with the Babel plugin) because it hurts refactor in IDEs and greps plus the whole ESM/cjs issues for non frontend code.
But what is not supported is to have anonymous component, and this memo wrapper looks like it (not sure). On top of fast refresh, the issue with anonymous function is unnamed layer in stacktrace & React devtools as Dan fro the core team mentioned often.

[maxstue]

Thank you I think i understand it a bit better now :)

In the project we already use that plugin.

Maybe it would be a better solution to refactor the components into smaller ones (if possible), so one doesn't import and handle too much 🤔

[ArnaudBarre]

Technically less files is better for toolchain performances, but that should not be the reason for files too big.
What you should avoid is export * from and make each file have a more explicit list of dependency. This also simplify the job for tolls if you do code splitting.

[maxstue]

Okay, so is it possible to do barrel files with more explicit exports like so (e.g. a components/ui folder)

export  { foo } from './foo'
export  { bar } from './bar'

or would that also make the HMR and code splitting less efficient?

[ArnaudBarre]

No the issue is with the fact to re-export not just export * so this would make HMR less efficient.

For code splitting technically it's not an issue, it's just more work for the bundler.

[maxstue]

Thanks for you help and explanation :)
I will now refactor the code to only use relative/absolute paths and now barrel files 👍

[devarsh]

Hi just curious if there is a plugin for MUI like library use-cases to support barrel imports and that gets transformed to direct import just like what babel-plugin-direct-import does for SWC.