Konubinix' opinionated web of thoughts

ECMAScript

fleeting

Created by TC39

document at https://tc39.es/ecma262/ is the most accurate and up-to-date ECMAScript specification

https://tc39.es/ecma262/

Realm

Before it is evaluated, all ECMAScriptV code must be associated with a realm. Conceptually, a realm consists of a set of intrinsic objects, an ECMAScript global environment, all of the ECMAScript code that is loaded within the scope of that global environment, and other associated state and resources

https://tc39.es/ecma262/#realm

.mjs extension

ESM

Before ES6 we really went out of our ways to obtain modules in JavaScript. Systems like RequireJS, Angular’s dependency injection mechanism, and CommonJS have been catering to our modular needs for a long time now – alongside with helpful tools such as Browserify and Webpack

https://ponyfoo.com/articles/es6-modules-in-depth

ES6 modules have been heavily influenced by CommonJS

https://ponyfoo.com/articles/es6-modules-in-depth

ES6 module system, strict mode is turned on by default. In case you don’t know what strict mode is, it’s just a stricter version of the language that disallows lots of bad parts of the language

https://ponyfoo.com/articles/es6-modules-in-depth

CommonJS, you export values by exposing them on module.exports

https://ponyfoo.com/articles/es6-modules-in-depth

could expose anything from a value type to an object, an array, or a function. module.exports = 1 module.exports = NaN module.exports = ‘foo’ module.exports = { foo: ‘bar’ } module.exports = [‘foo’, ‘bar’] module.exports = function foo () {}

https://ponyfoo.com/articles/es6-modules-in-depth

mimic the CommonJS code we just saw by changing module.exports = into export default. export default 1 export default NaN export default ‘foo’ export default { foo: ‘bar’ } export default [‘foo’, ‘bar’] export default function foo () {}

https://ponyfoo.com/articles/es6-modules-in-depth

export statements can only be placed at the top level in ES6 modules

https://ponyfoo.com/articles/es6-modules-in-depth

CommonJS you don’t even have to assign an object to module.exports first. You could just tack properties onto it

https://ponyfoo.com/articles/es6-modules-in-depth

module.exports.foo = ‘bar’ module.exports.baz = ‘ponyfoo’

https://ponyfoo.com/articles/es6-modules-in-depth

export var foo = ‘bar’ export var baz = ‘ponyfoo’

https://ponyfoo.com/articles/es6-modules-in-depth

ES6 modules export bindings, not values or references

https://ponyfoo.com/articles/es6-modules-in-depth

ES6 modules let you export lists of named top-level members. var foo = ‘ponyfoo’ var bar = ‘baz’ export { foo, bar }

https://ponyfoo.com/articles/es6-modules-in-depth

export something with a different name, you can use the export { foo as bar } syntax, as shown below. export { foo as ponyfoo }

https://ponyfoo.com/articles/es6-modules-in-depth

for the most part I’d encourage you to use export default

https://ponyfoo.com/articles/es6-modules-in-depth

will execute any code in the top level of the lodash module, though. import ’lodash’

https://ponyfoo.com/articles/es6-modules-in-depth

CommonJS you’d import something using a require statement, like so. var _ = require(’lodash’)

https://ponyfoo.com/articles/es6-modules-in-depth

import the default exported binding from an ES6 module, you just have to pick a name for it. The syntax is a bit different than declaring a variable because you’re importing a binding, and also to make it easier on static analysis tools. import _ from ’lodash’

https://ponyfoo.com/articles/es6-modules-in-depth

add some braces and pick any named exports you want

https://ponyfoo.com/articles/es6-modules-in-depth

import {map, reduce} from ’lodash’

https://ponyfoo.com/articles/es6-modules-in-depth

import to load new modules

ES6

Notes linking here