Modules, Namespaces & Project Structure

Question 1

What is the difference between ‘import’ and ‘require’ in TypeScript?

Answer 1

‘import’ is ES6 module syntax preferred in TypeScript; ‘require’ is CommonJS and commonly used in Node.js environments.

Question 2

What are internal modules (namespaces) in TypeScript?

Answer 2

Namespaces encapsulate code within a global scope using the ‘namespace’ keyword, mainly used in non-module environments.

Question 3

What are external modules in TypeScript?

Answer 3

External modules are individual files using ES6 module syntax like ‘import’ and ‘export’ to share and isolate code.

Question 4

What is a barrel file?

Answer 4

A barrel file is an index file that re-exports selected exports from other modules, simplifying imports for consumers.

Question 5

What is module resolution in TypeScript?

Answer 5

Module resolution is the process TypeScript uses to find and associate module specifiers with actual file paths.

Question 6

What are project references in TypeScript?

Answer 6

Project references allow a TypeScript project to depend on another project, enabling faster incremental builds and type sharing.

Question 7

What is an advantage of import/export syntax?

Answer 7

It promotes modular design, supports tree-shaking, and aligns with ES standards for compatibility with modern build tools.

Question 8

What is a disadvantage of using namespaces?

Answer 8

Namespaces are not well-supported in modern module-based systems and can conflict with bundlers and ES modules.

Question 9

What are the benefits of barrel files?

Answer 9

They reduce long relative import paths and centralize exports, improving developer experience and maintainability.

Question 10

What is a disadvantage of barrel files?

Answer 10

They can lead to circular dependencies and obscure the actual module dependency graph.

Question 11

What is the benefit of using module resolution paths via tsconfig?

Answer 11

It simplifies import paths and avoids fragile deep relative paths.

Question 12

What is a use case for project references?

Answer 12

Large monorepos with shared libraries or types used across multiple independent TypeScript projects.

Question 13

How do project references impact performance?

Answer 13

They enable incremental compilation, greatly reducing build times in large projects.

Question 14

What is a common issue when using namespaces?

Answer 14

They are not compatible with ES module systems and can cause issues with bundlers like Webpack or Rollup.

Question 15

What is a best practice for module resolution?

Answer 15

Define ‘baseUrl’ and ‘paths’ in tsconfig.json and ensure alignment across tools like Webpack and Jest.

Question 16

What is a best practice when using barrel files?

Answer 16

Avoid importing the barrel file from modules that it re-exports to prevent circular dependencies.

Question 17

What is a performance impact of project references?

Answer 17

They speed up builds by avoiding recompilation of unchanged projects, ideal for CI/CD pipelines.

Question 18

What is a real-world tradeoff of barrel files?

Answer 18

They simplify imports but may increase build and debug complexity due to hidden coupling.

Question 19

What is an example of using a barrel file?

Answer 19

An ‘index.ts’ file that exports members from ‘service.ts’, ‘model.ts’, and ‘utils.ts’.

Question 20

What is a common debugging tip for module resolution?

Answer 20

Use ‘tsc –traceResolution’ to trace how modules are being resolved by the compiler.

Question 21

What is the architectural implication of using project references?

Answer 21

They enforce strong boundaries and modularization in monorepo architectures.

Question 22

What is a best practice for project references?

Answer 22

Enable ‘composite’ and ‘declaration’ options in all referenced projects’ tsconfig files.

Question 23

What is the risk of deeply nested relative imports?

Answer 23

They become fragile and harder to refactor; path mapping can help mitigate this.

Question 24

What is a potential gotcha with module resolution?

Answer 24

Improperly configured ‘paths’ in tsconfig can lead to unresolved modules or runtime errors.

Question 25

What is the advantage of using external modules over internal ones?

Answer 25

External modules follow modern JavaScript standards and integrate better with tooling and ecosystems.

Question 26

What is a common interview question about module systems in TypeScript?

Answer 26

Explain the difference between internal (namespaces) and external (ES modules) in TypeScript and when to use each.

Question 27

What is a disadvantage of using project references?

Answer 27

They require more complex configuration and coordination between multiple tsconfig files.

Question 28

What is a debugging tip for circular dependencies in barrel files?

Answer 28

Temporarily remove the barrel file and import modules individually to detect dependency loops.

Question 29

What’s the difference between classic and node module resolution?

Answer 29

Classic is legacy and uses TypeScript’s custom rules; Node uses Node.js rules and is the default today.

Question 30

What’s a good way to organize modules in a large TypeScript app?

Answer 30

Use a layered structure with barrel files for each layer and project references for shared code.

Question 31

Can barrel files be used in a monorepo?

Answer 31

Yes, but they must be carefully managed to avoid circular dependencies and namespace pollution.

Question 32

What does 'composite: true' enable in tsconfig.json?

Answer 32

It allows a project to be referenced by others and enables incremental builds.

Question 33

What’s a gotcha with barrel files and tree-shaking?

Answer 33

If not carefully managed, tree-shaking might include unnecessary code from the barrel exports.

Question 34

What is a reason to prefer ES6 modules over namespaces?

Answer 34

They are standard-compliant, support static analysis, and work well with bundlers and modern toolchains.

Question 35

What happens if two projects reference each other in project references?

Answer 35

It creates a circular project reference, which will result in a compiler error.

Question 36

What is a monitoring strategy for debugging import issues?

Answer 36

Use consistent logging and compiler tracing tools to trace import paths and resolution behavior.

Question 37

What’s an architectural drawback of deep internal module trees?

Answer 37

They can lead to tight coupling and make the codebase harder to refactor or scale.

Question 38

What’s a real-world example of project references?

Answer 38

An enterprise monorepo where a 'common' library is referenced by both frontend and backend apps.

Question 39

What’s a best practice for naming barrel files?

Answer 39

Use 'index.ts' consistently to avoid confusion and align with community conventions.

Question 40

What is the performance implication of not using path aliases?

Answer 40

Refactoring imports is slower and build tools may take longer to resolve relative paths.

Question 41

Should barrel files be used in every folder?

Answer 41

Not necessarily—only use them where they simplify import statements without introducing coupling.

Question 42

What is the advantage of separating module logic by domain?

Answer 42

Improves maintainability and enforces clean boundaries between different application areas.

Question 43

What is a challenge with debugging circular imports?

Answer 43

They may result in partially loaded modules at runtime, causing undefined errors.

Question 44

What is a good rule for using imports in shared libraries?

Answer 44

Avoid importing from implementation-specific modules—import only from public barrel exports.

Question 45

What is the difference between 'export default' and 'export named'?

Answer 45

'default' allows a single export per module, while 'named' supports multiple explicit exports.