ESM

[xtuc]

The sources is now a ECMAScript module and is transpiled down to cjs before being published. User can consume the ESM build directly (which I do).

[CyDragon80]

Just my random Monday morning thought... (I might not be fully awake yet)
Is transpiling necessary or could one use metascript to flip the export line for common JS? Or is there more to it than the style of export?

Something along the lines of

// ES6 by default, but metascript can convert to a CJS version
//? if (typeof USE_CJS !== 'undefined') {
//?= 'module.exports = Long;'
//? } else {
export default Long;
//? }

"build:node": "metascript src/long.js -USE_CJS=true > dist/long.cjs.js"

Or perhaps to appease Travis, keep the original CJS and metascript a ES6 module version?

// CJS by default, but metascript can convert to a ES6 module version
//? if (typeof ES6_MOD !== 'undefined') {
//?= 'export default Long;'
//? } else {
module.exports = Long;
//? }

"build:esmod": "metascript src/long.js -ES6_MOD=true > es6mod/long.js",
. . .
"module": "es6mod/long.js",
"main": "src/long.js",

[xtuc]

Babel is not support in Node 0.12 anymore. @dcodeIO would you mind removing this legacy node version?

[MattiasBuelens]

Notice that export default function Long transpiles to exports.default = Long instead of module.exports = Long. This is a breaking API change: users will need to require the library differently (as you've done for the tests).

Even if you change the CommonJS transpilation to keep using module.exports, you may cause issues for Webpack users because of the module field, see webpack/webpack#4742. I ran into this myself with Two-Screen/stable#9, and we decided to remove the module field for now.

Not saying that we shouldn't support ESM. It's just really hard to do it without breaking backwards compatibility with other module loaders and bundlers. 😓