# Exporting Node Modules in 2022

DevFeed: [Exporting Node Modules in 2022](<https://devfeed.tech/articles/exporting-node-modules-in-2022-26220.md>)

Original publisher: [Read original article](<https://medium.com/groupon-eng/exporting-node-modules-in-2022-e8fd97f0f5a9?source=rss----5c13a88f9872---4>)

Author: David Bushong

Published: 2022-09-01T20:01:47Z

Content type: tutorial

Language: en

Sources: [Groupon Engineering -- Medium](<https://devfeed.tech/sources/groupon-engineering-medium.md>)

Topics: [CommonJS](<https://devfeed.tech/topics/commonjs.md>), [npm](<https://devfeed.tech/topics/npm.md>), [ECMAScript](<https://devfeed.tech/topics/ecmascript.md>), [TypeScript](<https://devfeed.tech/topics/typescript.md>), [Webpack](<https://devfeed.tech/topics/webpack.md>), [import](<https://devfeed.tech/topics/import.md>)

Tags: [babel](<https://devfeed.tech/tags/babel.md>), [commonjs](<https://devfeed.tech/tags/commonjs.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [import](<https://devfeed.tech/tags/import.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [node](<https://devfeed.tech/tags/node.md>), [npm](<https://devfeed.tech/tags/npm.md>), [typescript](<https://devfeed.tech/tags/typescript.md>), [webpack](<https://devfeed.tech/tags/webpack.md>)

## AI overview

This tutorial explains CommonJS and native ES Module exports in Node.js, including how modules can be imported across module systems. It also compares the output of Babel, Webpack, and TypeScript with native Node.js module behavior, highlighting compatibility concerns and TypeScript's non-standard export syntax.

## Source excerpt

Groupon maintains literally hundreds of NPM modules, both open source and internal. Many of these are consumed by our custom NodeJS-based middleware web layer we call "The Interaction Tier" (itself a topic for another post someday). As folks write new modules, a common question is "what's the best way to export things from our published modules to maximize compatibility?" -- and that is the topic of this post. First, some background and history: Flavors of exported modulesCommonJS in Node In the beginning, there was CommonJS: Here are 3 sample files with exports: // export1.js - exporting individual properties w/ CommonJS 'use strict';function foo() { } exports.foo = foo; exports.bar = 42;// export2.js - exporting a single object w/ CommonJS 'use strict';function baz() { } const garply = 88; module.exports = { baz }; // dynamically (conditionally!) exported! if (Math.random() > 0.5) module.exports.garply = garply;// export3.js - exporting a bare function w/ CommonJS 'use strict';function quux() { } module.exports = quux;// sometimes there are extra properties added to the bare function quux.yadda = 42; Those CommonJS exports can be imported either into other CommonJS files or into ES Module (more on that below) files: // import.js - importing CommonJS modules into a CJS file 'use strict';const { foo, bar } = require('./export1'); const { baz, garply } = require('./export2'); if (Math.random > 0.9) { // can also dynamically decide when to import const quux = require('./export3'); // can poke into properties tacked onto functions const { yadda } = require('./export3'); }// import.mjs - importing CommonJS modules into an ESM file // node is willing to turn exported objects into named exports import { foo, bar } from './export1.js'; import { baz, garply } from './export2.js'; import quux from './export3.js'; // cannot access added property "yadda" directly; hence: const { yadda } = quux; You can read more elsewhere, but the key features are: The module files are synchron