Gathering detailed insights and metrics for babel-plugin-transform-es2015-modules-commonjs-simple
Gathering detailed insights and metrics for babel-plugin-transform-es2015-modules-commonjs-simple
Gathering detailed insights and metrics for babel-plugin-transform-es2015-modules-commonjs-simple
Gathering detailed insights and metrics for babel-plugin-transform-es2015-modules-commonjs-simple
babel-plugin-transform-es2015-modules-simple-commonjs
Simplified imports and exports
babel-plugin-transform-es2015-modules-amd-simple
Alterntative to default babel-plugin-transform-es2015-modules-amd that does not mangle symbol names. Simply uses [babel-plugin-transform-es2015-modules-commonjs-simple](https://github.com/jamietre/babel-plugin-transform-es2015-modules-commonjs-simple) as
Alterntative to default module transformer that does not mangle symbol names
npm install babel-plugin-transform-es2015-modules-commonjs-simple
Typescript
Module System
Node Version
NPM Version
71.5
Supply Chain
98.5
Quality
72.8
Maintenance
25
Vulnerability
99.6
License
JavaScript (100%)
Total Downloads
400,849
Last Day
254
Last Week
998
Last Month
3,441
Last Year
40,266
MIT License
26 Stars
52 Commits
3 Forks
3 Watchers
2 Branches
2 Contributors
Updated on Mar 28, 2024
Latest Version
6.7.4
Package Id
babel-plugin-transform-es2015-modules-commonjs-simple@6.7.4
Size
12.48 kB
NPM Version
3.8.0
Node Version
4.2.2
Cumulative downloads
Total Downloads
Last Day
18.7%
254
Compared to previous day
Last Week
28.8%
998
Compared to previous week
Last Month
6.3%
3,441
Compared to previous month
Last Year
55.7%
40,266
Compared to previous year
20
Use ES6 Module Format While Preserving Imported Symbol Names
The regular babel-plugin-transform-es2015-modules-commonjs module mangles symbol names in order to implement the ES6 modules feature of exporting bindings rather than references or values.
However, JavaScript source maps don't currently support mapping symbol names. So when debugging using source maps, any imports will not be available under their original name, which is can make for a frustrating experience. This module ensures that all symbol names are preserved.
This module adds a noMangle
option that, when true, prevents variable names from being mangled.
This module also adds an addExport
option to allow modules with a single default export to be interoperable with CommonJS as they were in babel <6.
From npm:
1$ npm install --save-dev babel-plugin-transform-es2015-modules-commonjs-simple
If you are not using a babel preset, just include this module as a plugin instead of transform-es2015-modules-commonjs
and add the option noMangle: true
:
.babelrc
{
"plugins": [
"transform-es2015-arrow-functions",
"transform-es2015-tempalte-literals",
...
["transform-es2015-modules-commonjs-simple", {
"noMangle": true
}]
],
"sourceMaps": true
}
If you are using a preset, it probably already includes babel-plugin-transform-es2015-commonjs
. While you might be able to just add the plugin
to your .babelrc
, it doesn't appear to work reliably in all circumstances, so it's not recommended. See this discussion for details..
I wrote up some basic instructions on creating your own preset using this module transformer based on the native es2015
preset.
If you're just using the generic ES2015 preset, then someone's been gracious enough to create a package for the ES2015 babel preset that has everything except babel-plugin-transform-es2015-commonjs
, here.
So, with that installed:
.babelrc
{
"presets": [
"es2015-webpack"
],
"plugins": [
["transform-es2015-modules-commonjs-simple", {
"noMangle": true
}]
]
"sourceMaps": true
}
There's a package called modify-babel-preset which ought to let you override any preset with a lot less code. It's a good idea, and it would be nice to not have to keep your own preset "fork" in sync with the current default one. But it didn't seem to work for me; seems to need some updates for the latest version of babel.
When true, will prevent variable names from being mangled.
when true, will enable ES6 modules with a single default export to be used interoperably with CommonJS require
. This matches the functionality of Babel <6, and basically adds this to the end of modules with a single default export:
module.exports = exports['default'];
This allows you to use those modules as:
var foo = require('foo')
instead of
var foo = require('foo').default
npm install
All the tests from the native babel transform are under fixtures
. Tests that validate the new features are under nomangle
and addexport
npm test
You can run individual tests using a special convention, see test/index.js
Starting with 6.6.5, the versions of this package will track the versions of the official babel-plugin-transform-es2015-modules-commonjs
for simplicity. Since babel is monorepo, it's not possible to just fork the module itself, so I am tracking upstream changes in a fork babel.
There's a reason the native babel transform mangles variable names, and you might need this. The ES6 module format specifies that bindings, and not objects, are exported. This means if an exported entity mutates within the module, consumers that reference the exported entity will refer to the actual current value of the symbol, not the reference or value that was originally exported.
In order to implement the complete ES2015 feature set, when compiling ES2105 modules to CommonJS format, Babel changes references to imported symbols so they always made to refer a child property, e.g.
import foo from 'bar';
console.log(foo.text)
is transformed to
var _foo = require('bar');
var _foo2 = defaultExportInterop(_foo);
console.log(_foo2["default"].text)
Since the parent object never changes, any changes in values will always be current, as they are always resolved when evaluated.
This is a problem because source maps don't currently support mapping of symbol names. This makes degugging difficult if the names aren't the same as the source code. If you are writing good, modular code, you probably import a ton of symbols. If you are using source maps, you have probably been frustrated because none of your symbols are defined when debugging.
This plugin was created to give ES6 developers the option to sacrifice a feature that they may never use for the sake of preserving symbol names in the compiled code. This code with babel-plugin-transform-es2015-modules-commonjs-simple
becomes:
var _foo = require('bar');
var foo = defaultExportInterop(_foo).default;
console.log(foo.text)
This feature isn't especially well-known. Most articles that explain ES6 modules don't mention it at all. Dr.Rauschmayer of course does, since he knows all. That article does a good job of explaining why it could be useful.
However, this feature didn't exist with CommonJS modules. It's also unlikely that anything you consume from npm will use it today, since most everything on npm is expected to be a CommonJS module that runs in node, which doesn't know what an ES6 module is. So this is probably not happening anytime soon. If a module author today wants to export a binding, he's probably exporting an object and telling people to refer to properties of the object.
So if you don't plan to mutate your exports or create circular references in your own code, you should be quite safe to use this.
Sure! If you use require
to import modules instead of import
, then symbol names won't be mangled.
Personally, though, I would much rather write my code with a forward-compatible module syntax, and not use a feature, then write non-forward-compatible CommonJS modules that also don't use a feature that doesn't exist with CommonJS modules anyway.
Nothing at all. Using this module makes no demands on your source code, it just changes the compiled output. You can turn off the noMangle
option to restore the native babel behavior, or swap in the offical plugin with no code changes required.
When the noMangle
option is false, this is code-identical to the native babel source babel-plugin-transform-es2015-commonjs transform. This plugin tracks changes to the official transform, but extends it with the options described here.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 1/29 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2025-06-30
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More