JavaScript Modules (import/export) Quiz

JavaScript
0 Passed
0% acceptance

Answer 50 questions on ES modules: named vs default exports, import syntax variations, renaming, exporting functions/classes/constants, re-exporting, module scope, namespace imports, dynamic import(), browser/module loading, resolution rules, Node.js ESM/CommonJS, bundling basics, and best practices.

50 Questions
~100 minutes
1

Question 1

What is the primary advantage of ES modules?

A
Native support for importing/exporting scoped code
B
Automatic global variable sharing
C
Inline scripts only
D
Guaranteed bundler-free builds
2

Question 2

Which keyword exposes bindings from a module?

A
export
B
module
C
require
D
include
3

Question 3

How do you import a named export foo?

A
import { foo } from './module.js'
B
import foo from './module.js'
C
import foo as './module.js'
D
require('./module.js').foo
4

Question 4

What distinguishes default exports from named exports?

A
Only one default export per module; imported without braces
B
Default exports must be functions only
C
Named exports cannot exist alongside default
D
Default exports require aliasing
5

Question 5

How do modules execute compared to classic scripts?

A
Modules execute once, stay in strict mode, and share live bindings via imports
B
Modules run every time they are imported
C
Modules automatically join the global object
D
Modules disable strict mode
6

Question 6

Which attribute loads a browser script as an ES module?

A
<script type="module" src="main.js"></script>
B
<script module src="main.js"></script>
C
<script esmodule>
D
<script defer src="main.js"></script>
7

Question 7

Where do module-level variables live?

A
Inside the module scope only
B
window/globalThis automatically
C
Shared global scope for all modules
D
The DOM tree
8

Question 8

Why might you choose named exports over default?

A
Named exports communicate multiple public APIs explicitly
B
Default exports cannot be renamed
C
Named exports are faster
D
Default exports do not support tree shaking
9

Question 9

What happens if two modules import each other (a cycle)?

A
ESM handles cycles but some bindings may be undefined until initialization completes
B
Modules crash immediately
C
Only CommonJS allows cycles
D
Imports are ignored
10

Question 10

What is a module namespace object?

A
An object containing read-only live references to a module’s exports
B
The global object
C
A DOM interface
D
A JSON descriptor
11

Question 11

What does this module export?

javascript
export const API_URL = 'https://api.example.com'
export function fetchData() {}
export class ApiClient {}
A
Named exports API_URL, fetchData, ApiClient
B
Only default export
C
Nothing (syntax invalid)
D
API_URL as default
12

Question 12

How do you import every named export as a namespace?

javascript
import * as utils from './utils.js'
utils.log('hi')
A
Namespace imports gather all exports under an object
B
It only imports default
C
It clones the module for editing
D
It is invalid syntax
13

Question 13

Why is this import problematic?

javascript
import foo, { bar } from './module.cjs'
A
CommonJS modules typically do not provide named exports for ESM to destructure
B
The syntax is invalid JavaScript
C
bar must be default
D
module.cjs files cannot be used
14

Question 14

How do you rename a named export during import?

javascript
import { fetchData as request } from './api.js'
request()
A
Use import { original as alias } syntax
B
Change the name in the exporting module only
C
Use import alias request = fetchData
D
Renaming is impossible
15

Question 15

How do you rename a default export during import?

javascript
import Service from './service.js'
A
Assign any identifier when importing the default export
B
Use import { default as Service } without braces
C
Default exports cannot be renamed
D
Default exports must match the file name
16

Question 16

Which statement about default and named exports is accurate?

A
Modules may combine one default export with multiple named exports
B
Default exports forbid named exports
C
Named exports require a default export
D
Only one named export may exist
17

Question 17

How do you export a value inline?

A
Use export const MAX = 10
B
Assign to module.exports
C
Call export(MAX)
D
Use declare export const
18

Question 18

Which statement re-exports a binding without creating a local variable?

javascript
export { formatDate } from './date-utils.js'
A
It forwards formatDate so consumers can import from this module
B
It imports but does not export
C
It creates a default export
D
It is illegal syntax
19

Question 19

What does export * from "./module.js" accomplish?

A
Re-exports all named exports except default
B
Imports all bindings but keeps them private
C
Exports only default
D
Throws syntax error
20

Question 20

How do you import both the default export and named exports in one statement?

javascript
import Foo, { bar, baz } from './module.js'
A
Place the default identifier first, followed by named imports in braces
B
Use import { default Foo, bar }
C
Use two separate import statements
D
Only named exports support this
21

Question 21

What does module scope guarantee?

A
Top-level declarations remain private unless exported
B
Modules share a single global scope
C
Modules automatically register DOM globals
D
Variables become properties on window
22

Question 22

What does this namespace import log?

javascript
import * as math from './math.js'
console.log(Object.keys(math))
A
An array of exported binding names
B
Only the default export name
C
undefined
D
Throws because namespace imports are invalid
23

Question 23

How can you lazy-load a module only when a feature is needed?

javascript
async function loadFeature() {
  const module = await import('./feature.js')
  return module.init()
}
A
Use dynamic import(), which returns a promise resolving to the module namespace
B
Call require at runtime
C
Use synchronous import()
D
Dynamic importing is unsupported
24

Question 24

What does this module demonstrate about shared state?

javascript
let counter = 0
export function increment() {
  counter += 1
  return counter
}
A
Module-level variables persist between function calls and across importers
B
counter resets for each import
C
Each importer gets its own counter copy
D
counter is local to increment only
25

Question 25

Why should imported bindings be treated as read-only?

A
ESM enforces immutable bindings on the import side; assignments throw in strict mode
B
Changing imports automatically updates exporters
C
Imports are local variables only
D
Read-only imports break tree shaking
26

Question 26

What is tree shaking?

A
Bundlers remove unused imports/exports using static analysis
B
Dynamic import evaluation
C
Reloading modules at runtime
D
Manual deletion of code
27

Question 27

What does globalThis._importMeta_.url provide?

javascript
console.log(globalThis._importMeta_.url)
A
The absolute URL of the current module file
B
Only the directory path
C
The browser user agent
D
undefined outside Node.js
28

Question 28

How do import assertions help load JSON modules?

A
import data from './data.json' assert { type: 'json' } informs the loader about the format
B
Use require in browsers
C
JSON cannot be imported
D
Assertions automatically stringify JSON
29

Question 29

What does this code log when multiple files call increment()?

javascript
import { increment } from './counter.js'
console.log(increment())
A
A shared incrementing value because modules execute once
B
Always 1
C
undefined
D
Throws due to duplicate imports
30

Question 30

Why should circular dependencies be minimized?

A
They can expose partially initialized bindings and complicate reasoning about load order
B
They improve performance
C
They are disallowed by the spec
D
They disable tree shaking
31

Question 31

What does this import path imply in the browser?

javascript
import { render } from '../components/render.js'
A
Relative imports must include file extensions in browsers unless a build step rewrites them
B
Extensions are optional in browsers
C
render.js is searched via NODE_PATH
D
The browser resolves modules via package.json
32

Question 32

How does Node.js resolve ES modules by default?

A
It uses file extensions (.mjs, .js with type module, or package imports) and URL-style resolution
B
It falls back to require automatically
C
It ignores package.json type field
D
It loads modules from CDN only
33

Question 33

What does package.json "type": "module" do?

A
Treats .js files in that package as ES modules
B
Forces CommonJS everywhere
C
Disables import statements
D
Only affects browsers
34

Question 34

How do you import CommonJS modules inside an ES module in Node?

javascript
const pkg = await import('node:fs')
const fs = pkg.default || pkg
A
Use dynamic import() and read the default or namespace exports
B
Use require directly in ESM
C
CJS modules cannot be accessed
D
import() returns synchronous value
35

Question 35

What are package imports (e.g., "#utils")?

A
Custom module specifiers mapped via package.json "imports" field
B
Browser-only features
C
CDN paths
D
Dynamic import aliases
36

Question 36

What does this dynamic import in Node accomplish?

javascript
const { readFile } = await import('node:fs/promises')
A
Loads the ESM version of the fs promises API using async import
B
Calls require
C
Blocks the event loop
D
Only works in browsers
37

Question 37

What role do bundlers play in module-based projects?

A
They combine many ES modules into optimized bundles with features like minification and tree shaking
B
They replace import/export syntax with eval
C
They are only for CSS
D
They disable dynamic import
38

Question 38

Which statement about code splitting is true?

A
Bundlers rely on dynamic import() to create separate chunks loaded on demand
B
It requires CommonJS only
C
It eliminates the need for caching
D
It runs only on the server
39

Question 39

How can environment-specific modules be selected?

A
Use conditional exports in package.json to map specifiers to different files per environment
B
Use window.checkEnv()
C
Rename files at runtime
D
It is impossible
40

Question 40

Why is explicit file extension usage recommended in ESM?

A
It matches URL resolution semantics and avoids ambiguity across platforms
B
It only affects CommonJS
C
It speeds up bundlers dramatically
D
Extensions are optional everywhere
41

Question 41

How do you import CommonJS modules from ESM in Node if you need synchronous semantics?

A
Use createRequire from module to obtain a require function
B
Use require directly in ESM
C
Wrap import() in Promise.resolve
D
It is impossible
42

Question 42

What is the primary difference between CommonJS and ES modules?

A
CommonJS is synchronous with module.exports/require; ESM is static and asynchronous-friendly
B
CommonJS supports top-level await
C
ESM lacks import/export
D
CommonJS executes in strict mode automatically
43

Question 43

Why should module specifiers avoid file-system specific assumptions?

A
Modules may run in browsers, Node, or bundlers with different resolution rules
B
Specifiers must be absolute URLs only
C
Modules run only in browsers
D
Relative paths are forbidden
44

Question 44

What is a common pattern for organizing exports in large projects?

A
Create barrel modules that re-export modules from feature folders
B
Define all code in index.js
C
Use dynamic eval to gather exports
D
Avoid re-exports entirely
45

Question 45

Why is using consistent file extensions important when mixing ESM and CJS in Node?

A
.mjs and .cjs (or type field) tell Node which module system to use
B
Extensions are ignored entirely
C
Node treats all .js as CommonJS regardless
D
ESM requires .esm extension
46

Question 46

Why should you avoid mixing default exports with too many named exports in the same file?

A
It can confuse consumers; separate modules or barrel files keep APIs clearer
B
The spec forbids it
C
Tree shaking breaks
D
It slows down bundlers
47

Question 47

Which best practice helps prevent accidental default export renames?

A
Prefer named exports for most APIs and reserve default for singular concepts
B
Always export default objects
C
Use export default for every file
D
Avoid named exports entirely
48

Question 48

Why should environment-specific configuration be isolated into separate modules?

A
It allows bundlers or conditional exports to pick the right file per environment
B
It is required by the spec
C
It disables tree shaking
D
It prevents code splitting
49

Question 49

What is a recommended strategy for module organization in large apps?

A
Group modules by feature/domain and expose public APIs via index.ts/index.js per folder
B
Dump everything into a single utilities module
C
Rely on deep relative imports between unrelated folders
D
Avoid documenting module boundaries
50

Question 50

Which best practice improves readability when importing many bindings?

A
Prefer namespace imports or barrel exports to reduce long import lists
B
Alias everything to single-letter names
C
Use default export for every binding
D
Inline require statements inside functions

QUIZZES IN JavaScript