A barrel module imports and re-exports several child modules to create a single import point. It is useful for grouping related features. It becomes an anti-pattern when it re-exports everything indiscriminately, groups unrelated modules for convenience, or triggers unnecessary recompilation of all consumers on any child module change.
Re-exporting everything — exposes internal implementation details that should stay private.
Grouping unrelated modules — creates false cohesion and obscures the real dependency graph.
Large monorepo barrels — every change to a child module triggers recompilation of all barrel consumers.
Use barrels only for genuine bounded contexts; only re-export the public surface, not every internal module.
You have a feature module that needs three services from the same folder. How would you use a barrel file to simplify the imports?
If you add a new service to a barrel index but forget to export it, what runtime error would you expect when the app starts?
When would you decide not to create a barrel file in a small NestJS project?
During a code review you notice a barrel that re‑exports many feature modules and the build time has grown. What could be causing the slowdown and how would you address it?
You refactored a set of providers into a shared barrel, and now a circular‑dependency error appears. Explain why this happened and how you would resolve it.
In a monorepo with several teams, what are the trade‑offs of exposing a public API via barrel modules versus explicit imports?
Your core library uses barrel modules extensively, but lazy‑loaded modules are being eagerly loaded at runtime. How would you detect this and restructure the exports?
Explain how barrel modules affect tree‑shaking and bundle size when the NestJS app is compiled with webpack, and what strategies you’d use for a large codebase.
When scaling a NestJS microservice architecture, what runtime or deployment pitfalls can arise from overusing barrel modules, and how would you redesign them?
Your organization is migrating a legacy NestJS codebase that heavily relies on barrel modules to a new modular monorepo. What architectural guidelines would you set to prevent barrels from becoming an anti‑pattern, and how would you manage the transition across multiple teams?
Some teams want to expose internal utilities via barrel files while others need strict encapsulation. How would you define policies and tooling to balance ease of use with long‑term maintainability?