Import Named Exports
By default, expressions and assignments declared inside a module aren’t available outside of that module.
function hype(message) {  return `${message.toUpperCase()}!!!`}Here, hype is only available to other functions inside string-utils.mjs.
We can expose hype to other modules by prepending the export keyword.
 function hype(message) { export function hype(message) {  return `${message.toUpperCase()}!!!`;}hype is now a named export from the string-utils module.
Keep in mind that export-ing something doesn’t mean it is automatically available throughout the codebase. Every export requires an import.
Import named exports
Anything one module exports can be imported and used by another module.
import {hype} from './string-utils.mjs'
console.log(hype('moduuuules'))// => MODUUUULES!!!The syntax we use to access named exports is similar to object destructuring assignment.
let person = {name: 'chantastic'}let {name} = personWe can only import what we can access by name.
So, the import statement below would fail (with our current module):
import {  hype,  chant /* oops. no chant */,} from './string-utils.mjs'
// SyntaxError:// The requested module './string-utils.mjs' does not provide an export named 'chant'Import multiple named modules
We can import as many named exports as we like!
Let’s implement and export a chant function:
export function hype(message) {  return `${message.toUpperCase()}!!!`;}
 export function chant(message) {   return [...Array(3)].map(() => message).join("! "); }import {hype, chant} from './string-utils.mjs'
console.log(chant('M'))// => Modules! Modules! Modules!My take
Named exports are the module feature I use most.
The major downside of named exports is naming collisions with other modules.
In future posts I’ll share a handful of strategies to compensate for and avoid naming collisions of named exports.
Go pro
This is part of a course I’m build on modules at lunch.dev.
When live, members get access to this and other courses on React.