Sorry for the misunderstanding about naming. Unfortunately, I had a chance to see similar names in real apps and somehow wrongly assumed that you also want to use this convention. When it comes to "ending up either with huge files that have everything piled up or super-tiny files". This is a matter of finding a good balance. I don't mind a lot of small files (js modules), that are focused on a single functionality - it is a sign that one has correctly distilled smaller responsibilities from some bigger use case. This produces code that is simpler to understand, test and maintain. The big files (js modules) or big classes/functions are often a sign that SRP is broken. Regarding sandbox.io example - I can't wrap my head around it and don't understand the intentions behind hello and world functions. They are just simple functions that recursively call each other (causing stack overflow). The simplest refactor would be to just use a shared function like e.g. buildGreeting(msg1, msg2) placed in foobar directory. Export const world = 'world' from foo directory, and const hello = 'hello' from bar directory, then in some other sibling directory create a module with a call like:

import {hello} from '../foo'
import {word} from '../bar'

buildGreeting(hello, word);

However, it is challenging to illustrate any meaningful improvement over this example code, because it does not illustrate any real use case.

Your example seems to be quite generic, so I try to describe some general rules of thumbs, but they may be somehow opinionated.

1. If there is a circular dependency between foo and bar the simplest approach to eliminate it is to extract all circularly dependent units into a separate module/directory e.g. foobar. You mentioned this solution, but the direction of dependencies should be different. Both foo and bar should require foobar that provides the extracted shared code. This way you can still import separately foo and bar (transiently importing foobar).
2. This applies also to every functions/types/enums/interfaces you mentioned - if something is used by both foo and bar then it should be placed in a separate module/directory.
3. Regarding names like functions/types/enums/interfaces - I would consider using such names as a last resort (e.g. as names for leaves directories in directories tree), because they communicate information that most often is irrelevant. A much better approach is to organize (colocate) code around business domain concepts instead of names related to implementation details. This increases code discoverability and makes code organization less fragile. e.g. instead of

<sourcesRoot>/api/functions/getUser.ts
<sourcesRoot>/api/functions/getPosts.ts
<sourcesRoot>/api/enums/UserRole.ts
<sourcesRoot>/api/types/User.ts
<sourcesRoot>/api/types/Post.ts
<sourcesRoot>/api/index.ts

... consider using:

<sourcesRoot>/users/api/getUser.ts
<sourcesRoot>/users/model/User.ts
<sourcesRoot>/users/model/UserRole.ts
<sourcesRoot>/users/index.ts

<sourcesRoot>/posts/api/getPosts.ts
<sourcesRoot>/posts/model/Post.ts
<sourcesRoot>/posts/index.ts

4. Keep foo and bar small. Try to distill some sub-domains/areas/contexts from foo or bar into separate directories. This should generate smaller index.ts files.
5. This one may be opinionated and unpopular... consider avoiding barrel files. In my opinion barrel file works nicely if you publish a library. In such a case you can specify precisely public members (assuming CommonJS module). However, barrel files on lower levels in the directories tree don't provide much value in my opinion. You can still import modules directly (bypassing barrel file). They make refactoring slower because in many cases you need to manually update barrel files. If you forget to update them, they occasionally create a very nasty circular dependency that at the runtime manifests itself in the form of undefined values. You may have imports paths that look cleaner but in practice one very rarely works manually with imports paths. This is a job for the IDE.