make sure that you are not inside of the app folder and than the need for the "use client" is not required

Really? I'll give it a go. Do you export other things from the module? That are maybe used in a Server Component?

Yeah ...

But I have this module with hook outside my app folder. Does it influence to the end result or not?

I'm not sure, does it some next.js bug, or I do smth. wrong?

Seeing the import chain as a graph is important, otherwise just importing can often to lead to unpredictable, or non-intuitive issues.

In this commit for example icyJoseph/next-js-react-gbg@3610a9d I fixed a problem where importing a simple string constant, from a file that contained a function that used crypto, lead to browserify crypto being included on my client bundle. That's about 200kB I surely did not want...

In your case I think, you import colors from a file that in turn re-exports imports from other files, one of them ends up in a component that uses client component hooks, and since the top level importer is a Server Component, it breaks.

@icyJoseph, I suppose you're right!

I've changed my code like this and it fixed my problem.

A @core dir in my project has this kind of structure

And I do kind of shortcut in my tsconfig file to make import paths shorter

I've also did like that in me core/index.ts and error also been fixed

So, i have my reusable react components and other stuff in my core folder.
Do I need now to have kinda coreClient & coreServer folders to avoid such conflicts?

So, both useOpen hook & my coors constant imports from the same index.ts

Yeah, I suppose the root issue here is that certain tooling has created an expectation with regards to tree shaking and code splitting, which in turn lead to the so-called barrel file pattern. Where modules are re-exported by an entry point.

We are also kind of blindly trusting webpack through next.js, plus the plugins and actual implementation, so the less we assume and take for granted the better.

This was already problematic when testing. For example Jest, would enter the barrel file and parse everything, absolutely, and then take the one little thing you actually want to test. When barrel files mixed code from various environments, you ended up with failed tests, och absurd mocks just get going. Say testing within jsdom and hitting a Node API.

Now that server components present the module as the boundary, barrel files are even more strange. They could break environment isolation, and are somewhat redundant step since the modules they re-export, are already public.

Obviously if the re-exported members of a barrel file are all agnostic to the environment, or belong to the same environment, then we are good.

So yeah, you are probably better off separating your code by environment.

Some libraries export conditionally too, but that's a topic I won't go into, for various reasons.