Unexpected logging for dev server

[n2k3]

Describe the Bug

When running the dev server in my local project (I don't have a monorepo/workspaces) with this commandbunx --bun email dev --dir ./src/emails --port 3010
it logs:

/Users/paul/.bun/bin/bun run email
$ bunx --bun email dev --dir ./src/emails --port 3010
    React Email 4.2.8
    Running preview at:          http://localhost:3010

  ✔ Ready in 0.2s

Could not find index file for directory at /Users/paul/src/virtoura/dbschema/edgeql-js/modules/std. This is probably going to cause issues with both hot reloading and your code.
Could not find index file for directory at /Users/paul/src/virtoura/dbschema/edgeql-js/modules/ext. This is probably going to cause issues with both hot reloading and your code.
Could not find index file for directory at /Users/paul/src/virtoura/dbschema/edgeql-js/modules/std. This is probably going to cause issues with both hot reloading and your code.
Could not find index file for directory at /Users/paul/src/virtoura/dbschema/edgeql-js/modules/std/net. This is probably going to cause issues with both hot reloading and your code.
Could not find index file for directory at /Users/paul/src/virtoura/dbschema/edgeql-js/modules/std/net. This is probably going to cause issues with both hot reloading and your code.
... and a bunch more

Why is it looking for files to hot module reload outside of the provided directory?

Proposal:

1. don't look for files with supported extensions outside of the provided --dir <directory> argument
2. or it could be fixed by reading/using .gitignore file (the directories of the log are listed there)

Which package is affected (leave empty if unsure)

react-email

Link to the code that reproduces this issue

N/A

To Reproduce

1. have files .ts files in the repository in a directory outside of the provided --dir that don't have an index.ts
2. start dev server with --dir ./src/emails argument
3. see the logs of directories

Expected Behavior

I would expect the the logging to not appear, as it is confusing.

Note: The hot module reload just works for the actual email component files in the ./src/emails folder.

What's your node version? (if relevant)

bun 1.2.20 (also happens on Node v22.17.0)

[NikhilRaikwar]

👋 I'd like to work on this issue

Hi maintainers,
I'd like to take on this issue. I've analyzed the problem and have a clear understanding of what's causing it.

My Understanding
The dev server is logging warnings about missing index files in directories outside the specified --dir argument (like node_modules or other project directories). This happens because the dependency graph creation in create-dependency-graph.ts recursively follows all imports and logs warnings for any directory without an index file, regardless of whether it's within the emails directory or not.

Proposed Solution
I plan to modify the warning logic in packages/react-email/src/utils/create-dependency-graph.ts to:

1. Only show warnings for files/directories within the specified --dir path
2. Suppress warnings for dependencies outside the emails directory (node_modules, etc.)
3. Maintain all existing hot-reloading functionality

This will eliminate the confusing noise while keeping relevant warnings that actually matter to the user.
Implementation Approach

• Add boundary checking using path.relative() before logging warnings
• Keep the dependency graph tracking all files (for proper hot reloading)
• Only filter out the warning messages for external dependencies

Could you please assign this issue to me? I'm ready to start working on it and can submit a PR soon.

Thanks!

[gabrielmfern]

@NikhilRaikwar I suppose not warning is the way to go anyway, but from looking at the issue and back at the code, imports for node modules like import ... from '@react-email/components', for example, shouldn't get to the portion of the code that causes warnings.

The issue doesn't give good reproduction steps for that in that sense, but the real issue seems to be that in my eyes

[NikhilRaikwar]

Thanks for the insights @gabrielmfern. I’m rechecking my steps and will try again to put together a minimal reproduction to verify why these warnings appear outside the specified directory. The current fix I’ve implemented uses path.relative() to ensure warnings are only logged for files inside the given --dir path, which should suppress confusing logs from unrelated directories while maintaining hot reload functionality.