ES Modules — Barrel Files Kill Tree-Shaking

Q: When should I use a default export vs a named export?

Industry standard at TheCodeForge suggests using named exports for utilities and constants because they force consistent naming across the codebase. Use default exports only for the 'Single Responsibility' of a file, like a specific React component. Avoid 'mixing' both in one file as it makes the import syntax cumbersome for other developers.

Q: Can I import a CommonJS module in an ES Module file?

Yes, in Node.js, you can use `import defaultExport from './file.cjs'`. Node will wrap the `module.exports` of the CJS file as the default export of the ESM import. However, you cannot use `require()` inside an ES Module file; you must stick to `import`.

Q: Why do I get 'Uncaught SyntaxError: Cannot use import statement outside a module'?

This happens in the browser when you forget to add `type='module'` to your ` ` tag. Without this attribute, the browser treats the file as a legacy script where 'import' is a reserved word but not a functional command.

Q: Does 'import' copy the value or create a reference?

ES Modules provide 'live bindings.' If a module exports a variable and then changes its value, the importing module sees that change. This is a major difference from CommonJS, which exports a snapshot/copy of the value at the time of the require call.

Q: How do I use dynamic import in Node.js without bundlers?

Dynamic `import()` is supported natively in Node.js 14+. Just call `await import('./module.js')` inside an async function or at the top level if your module is ESM (since ESM supports top-level await). Ensure the file extension is included and the path is relative to the current file (using `import.meta.url` for absolute paths if needed).

Q: What is a barrel file and why is it problematic?

A barrel file is an `index.js` (or similar) that re-exports everything from multiple modules. Example: `export { Button } from './Button'; export { Card } from './Card';`. Problem: bundlers treat barrel as a single entry point and cannot tree-shake individual exports — they include everything. Also, circular dependencies are more likely. Better to import directly from the module file instead of the barrel.

An update added 35KB to your bundle? A barrel file with a default export likely blocked tree-shaking.

Naren Founder & Principal Engineer

20+ years shipping production JavaScript and front-end systems at scale. Notes here come from systems that actually shipped.

✓ Production

production tested

May 24, 2026

last updated

1,554

articles · all by Naren

● Production Incident 🔎 Debug Guide ⚙ Triage Commands

⚡Quick Answer

ESM uses export to expose and import to consume — no more global pollution
Named exports (export const) force explicit naming at import site, improving refactoring
Default exports (export default) are for the file's primary responsibility, rename without as
Dynamic import() returns a Promise — lazy load modules on user interaction

In Node.js, enable ESM with "type": "module" in package.json; browsers use



    Module System Comparison
Property ESM CommonJS AMD UMD
Introduced ES2015 (2015) 2009 (Node.js) 2011 (RequireJS) 2014 (Universal)
Static/Dynamic Static Dynamic Dynamic Dynamic
Syntax import / export require / module.exports define([...], function) wrapping pattern
Tree-shakable Yes No No No
Top-level await Yes No No No
Browser native Yes (modern) No (needs bundler) Yes (RequireJS) Yes (AMD or CJS fallback)
Node.js native Yes (v12+) Yes (default) No No

    Key takeaways
1Named exports (export const X) require curly braces and support Tree Shaking better than default exports.
2Default exports (export default X) are best for primary classes or components; they don't require braces.
3Dynamic import() is a function that returns a Promise—ideal for code splitting and reducing initial bundle size.
4ES Modules are static
imports must be at the top level and are hoisted. CommonJS require() is dynamic and can be called inside loops.
5In ESM, global variables like __dirname are replaced by import.meta.url patterns.
6Set `"sideEffects"
false` in package.json to enable tree shaking for your library.
7Avoid barrel files
they block tree shaking and introduce fragile re-export chains.

    Common mistakes to avoid
4 patterns
×Using `import` without adding `type="module"` to the script tag
Symptom
Browser throws SyntaxError: Cannot use import statement outside a module. App fails to load with no clear stack trace in production because minifiers may swallow the error.
Fix
Add type="module" to the <script> tag. If using a bundler, ensure it outputs in a format that doesn't require the attribute (bundled output usually runs as normal scripts).
×Forgetting the file extension in imports when targeting browsers
Symptom
Browser returns a 404 for the import path because the server can't resolve extensionless modules. Node.js may also fail if resolve.extensions doesn't include .js.
Fix
Always include the full file extension in browser imports: import { helper } from './helpers.js'. In bundlers, configure resolve.extensions appropriately. For Node.js ESM, extensions are required unless using experimental-specifier-resolution=node.
×Mixing default and named exports in a barrel file
Symptom
Tree-shaking fails, bundle grows. Developers are confused about which syntax to use when importing. Some tools (like ESLint import/export rules) may report false positives.
Fix
Avoid barrel files entirely. If you must use them, export only named exports and avoid default exports in the barrel. Alternatively, export a single default object containing all named exports.
×Trying to use `require()` inside an ES Module file
Symptom
Node.js throws ReferenceError: require is not defined because ESM does not have require in the global scope. Some older patterns like const fs = require('fs') stop working.
Fix
Replace require() with import. If you need dynamic behaviour, use await import() instead. For interop, consider using the createRequire function from module module to create a local require function.

    

    

  
    
      INTERVIEW PREP · PRACTICE MODE
      Interview Questions on This Topic
    
    
      
      
    
  

  
  
    Q01SENIOR
Explain 'Tree Shaking' and why ES Modules make it possible while CommonJ...
Q02SENIOR
What is the 'Static Analysis' benefit of ESM over CJS?
Q03SENIOR
How do you simulate `__dirname` in a Node.js ES Module environment?
Q04SENIOR
What happens if two modules have a circular dependency in ESM vs. Common...
Q05SENIOR
Implement a dynamic import loader that retries the network request 3 tim...
Q06SENIOR
Compare 'Default' and 'Named' exports in terms of refactorability in a l...
    Q01 of 06SENIOR
Explain 'Tree Shaking' and why ES Modules make it possible while CommonJS makes it difficult.
ANSWER
Tree shaking is dead code elimination that removes unused exports from the final bundle. ES Modules enable it because their import/export statements are static — they appear at the top level and are never conditional. This allows bundlers to statically analyse which exports are actually imported. CommonJS requires() can be dynamic (called inside if-blocks, loops, or functions), so the bundler cannot safely determine which exports are used without executing the code. Therefore, CommonJS modules are included in their entirety.
Q02 of 06SENIOR
What is the 'Static Analysis' benefit of ESM over CJS?
ANSWER
Static analysis means the bundler (or analyser) can parse the import/export statements without executing the code. This enables: (1) tree shaking — removing unused exports; (2) deterministic module graph — no race conditions; (3) faster bundling — because the dependency graph is known upfront; (4) dead code detection in linting — tools like ESLint can report unused imports. CommonJS requires code execution to resolve the module graph, which is why tools like Webpack had to use static analysis heuristics that often fail.
Q03 of 06SENIOR
How do you simulate `__dirname` in a Node.js ES Module environment?
ANSWER
In ESM, __dirname and __filename are not available because the module system doesn't use those globals. Use import.meta.url to get the file URL of the current module, then convert it to a path using the fileURLToPath function from the url module: import { fileURLToPath } from 'url'; import { dirname } from 'path'; const __filename = fileURLToPath(import.meta.url); const __dirname = dirname(__filename);. Alternatively, Node.js 22+ includes import.meta.dirname and import.meta.filename as experimental features.
Q04 of 06SENIOR
What happens if two modules have a circular dependency in ESM vs. CommonJS?
ANSWER
In CommonJS, circular dependencies are handled by returning a partial copy of module.exports that may be incomplete if the dependency is not yet fully exported. This can lead to undefined values for exports that are defined later. In ESM, because exports are live bindings, circular dependencies work more gracefully: importing modules see the current state of the exported variable, which starts as undefined and later gets the actual value. However, you must still avoid relying on the value of a binding before it is initialized — any export that uses let or var can be accessed before its initializer runs (hoisted), but const exports have a temporal dead zone. Best practice: avoid circular dependencies entirely by refactoring shared logic into a third module.
Q05 of 06SENIOR
Implement a dynamic import loader that retries the network request 3 times if it fails.
ANSWER
``javascript
export async function importWithRetry(modulePath, retries = 3, delay = 1000) {
  for (let attempt = 1; attempt <= retries; attempt++) {
    try {
      return await import(modulePath);
    } catch (error) {
      if (attempt === retries) {
        throw new Error(Failed to load ${modulePath} after ${retries} attempts: ${error.message});
      }
      console.warn(Attempt ${attempt} failed for ${modulePath}, retrying in ${delay}ms...);
      await new Promise(resolve => setTimeout(resolve, delay));
      delay *= 2; // exponential backoff
    }
  }
}
// Usage: const { runHeavyAudit } = await importWithRetry('./heavy-analytics.js');
``
In production, also consider a timeout for each attempt to avoid hanging indefinitely on a slow network.
Q06 of 06SENIOR
Compare 'Default' and 'Named' exports in terms of refactorability in a large-scale codebase.
ANSWER
Named exports are far more refactorable because each import uses the exact exported name. When you rename a named export (e.g., export const fetchUser => export const loadUser), your IDE can automatically update all imports that use that name. Default exports can be imported under any name (e.g., import MyComponent from './button' or import Button from './button'), so renaming the default export doesn't change import names. This makes it nearly impossible to track all usages of a default export without manual searching. In a large codebase with hundreds of modules, default exports lead to naming inconsistencies and increased cognitive load during refactoring. Recommendation: use named exports for all utilities, hooks, helpers, and multiple items; use default exports only for single-export components where the filename is the authoritative name (and enforce a lint rule that the default import name must equal the filename).
  

  
  
    01
Explain 'Tree Shaking' and why ES Modules make it possible while CommonJS makes it difficult.
SENIOR
02
What is the 'Static Analysis' benefit of ESM over CJS?
SENIOR
03
How do you simulate `__dirname` in a Node.js ES Module environment?
SENIOR
04
What happens if two modules have a circular dependency in ESM vs. CommonJS?
SENIOR
05
Implement a dynamic import loader that retries the network request 3 times if it fails.
SENIOR
06
Compare 'Default' and 'Named' exports in terms of refactorability in a large-scale codebase.
SENIOR
  



    

  
    FAQ · 6 QUESTIONS
    Frequently Asked Questions
  
  01
When should I use a default export vs a named export?
Industry standard at TheCodeForge suggests using named exports for utilities and constants because they force consistent naming across the codebase. Use default exports only for the 'Single Responsibility' of a file, like a specific React component. Avoid 'mixing' both in one file as it makes the import syntax cumbersome for other developers.
Was this helpful? 
02
Can I import a CommonJS module in an ES Module file?
Yes, in Node.js, you can use import defaultExport from './file.cjs'. Node will wrap the module.exports of the CJS file as the default export of the ESM import. However, you cannot use require() inside an ES Module file; you must stick to import.
Was this helpful? 
03
Why do I get 'Uncaught SyntaxError: Cannot use import statement outside a module'?
This happens in the browser when you forget to add type='module' to your <script> tag. Without this attribute, the browser treats the file as a legacy script where 'import' is a reserved word but not a functional command.
Was this helpful? 
04
Does 'import' copy the value or create a reference?
ES Modules provide 'live bindings.' If a module exports a variable and then changes its value, the importing module sees that change. This is a major difference from CommonJS, which exports a snapshot/copy of the value at the time of the require call.
Was this helpful? 
05
How do I use dynamic import in Node.js without bundlers?
Dynamic import() is supported natively in Node.js 14+. Just call await import('./module.js') inside an async function or at the top level if your module is ESM (since ESM supports top-level await). Ensure the file extension is included and the path is relative to the current file (using import.meta.url for absolute paths if needed).
Was this helpful? 
06
What is a barrel file and why is it problematic?
A barrel file is an index.js (or similar) that re-exports everything from multiple modules. Example: export { Button } from './Button'; export { Card } from './Card';. Problem: bundlers treat barrel as a single entry point and cannot tree-shake individual exports — they include everything. Also, circular dependencies are more likely. Better to import directly from the module file instead of the barrel.
Was this helpful? 



    📖 What to Read Next
→Node.js Modules and CommonJSMaster CommonJS module patterns in Node.js and understand how they differ from ESM for legacy projects.→CSS Preprocessors — SASS LESSRelated: CSS Preprocessors — SASS LESS on TheCodeForge.→Memoisation in JavaScriptRelated: Memoisation in JavaScript on TheCodeForge.→async and await in JavaScriptRelated: async and await in JavaScript on TheCodeForge.→Promises in JavaScriptRelated: Promises in JavaScript on TheCodeForge.
    

    
    
      
        N
        
          
            Naren
            Founder & Principal Engineer
          
          
            20+ years shipping production JavaScript and front-end systems at scale. Notes here come from systems that actually shipped.
          
        
        
          
          Follow
        
      
      
        
          
            ✓ Verified
          
          production tested
        
        
          May 24, 2026
          last updated
        
        
          1,554
          articles · all by Naren
        
      
    

    
    
      🔥
      
        That's Advanced JS. Mark it forged?
      
      
        5 min read · try the examples if you haven't

Property	ESM	CommonJS	AMD	UMD
Introduced	ES2015 (2015)	2009 (Node.js)	2011 (RequireJS)	2014 (Universal)
Static/Dynamic	Static	Dynamic	Dynamic	Dynamic
Syntax	import / export	require / module.exports	define([...], function)	wrapping pattern
Tree-shakable	Yes	No	No	No
Top-level await	Yes	No	No	No
Browser native	Yes (modern)	No (needs bundler)	Yes (RequireJS)	Yes (AMD or CJS fallback)
Node.js native	Yes (v12+)	Yes (default)	No	No