thread-loader-bug

This is a bug report for a JavaScript build tool issue. Someone discovered that when using a tool called thread-loader (which speeds up builds by running certain tasks in parallel), an important piece of information gets lost in the process.

Specifically, the problem is that LoaderContext.mode — a setting that tells the build system what mode it's running in (like development or production) — becomes undefined when thread-loader is active. This matters because many build tools need to know the mode to apply the right optimizations or configurations. In the example shown, the output shows 'mode is: undefined' instead of showing the actual mode value.

The repo demonstrates that the bug is reproducible: when you remove thread-loader from the configuration and rebuild, the mode is properly passed through and displays correctly. This tells us the bug is specifically about how thread-loader handles or passes along the mode information when it runs tasks in parallel.

This would be relevant to developers who are trying to speed up their builds using thread-loader but find that their code or build pipeline isn't working correctly because it can't access the mode information it needs. For example, someone might want to run different code paths based on whether they're building for development (with extra debugging) or production (with minification), but the mode being undefined breaks that logic.

The README is minimal because this is a focused bug report rather than a full project — it's meant to help someone (likely the maintainers of thread-loader) understand and reproduce the exact problem so they can fix it.