medikoo

List of ECMAScript 6 shims

Implemented on top of ECMAScript 5

Provided as distinct CJS modules, installable via npm

---

ECMAScript 5 Built-in Objects extensions

Individual modules of es5-ext package. See ES6 features for usage information.

Array

jeffmo

ES7 Class Properties

**~~ NOTE: This is a Stage 0 proposal. ~~**

This proposal has been moved to https://github.com/jeffmo/es-class-properties.

Please direct all future feedback to that repo in the form of directed issues.

lukehoban

Note: Up to date version now at https://github.com/lukehoban/es6features

ECMAScript 6

Introduction

ECMAScript 6 is the upcoming version of the ECMAScript standard. This standard is targetting ratifcation in December 2014. ES6 is a significant update to the language, and the first update to the language since ES5 was standardized in 2009. Implementation of these features in major JavaScript engines is underway now.

See the draft ES6 standard for full specification of the ECMAScript 6 language.

ES6 includes the following new features:

tbranyen

// Anonymous empty module.
define();

// Anonymous values.
define({});
define(true);
define(1234);
define(null);
define(undefined);

wycats

// A. Create a new object that will contain the names ES6 module exports. We create it immediately so that
// it will work across cycles.
var es6Out = {};

// B. Assign it immediately to module.exports so other files that try to require this file will see it
// right away.
module.exports = {
  __es6_module__: es6Out
};

dherman

Notational Conventions

This section describes the conventions used here to describe type signatures.

A [T] is an array-like value (only ever used read-only in this API), i.e., one with an integer length and whose indexed properties from 0 to length - 1 are of type T.

A type T? should be read as T | undefined -- that is, an optional value that may be undefined.

Realms

dherman

Notational Conventions

This section describes the conventions used here to describe type signatures.

A [T] is an array-like value (only ever used read-only in this API), i.e., one with an integer length and whose indexed properties from 0 to length - 1 are of type T.

A type T? should be read as T | undefined -- that is, an optional value that may be undefined.

Loaders

jrburke

Design forces:

• ECMAScript (ES) Module Loader API is coming. The ES module ID syntax are strings that are just treated as string IDs and not paths.
• Existing JS module experience in CommonJS/Node/AMD worlds of using module IDs that are resolved to a URL/path for fetching.
• Better package managers are coming for front end web apps. These package managers install assets by IDs not by paths.
• For front end code, baseURL + moduleID + '.js' is likely the default ID-to-URL resolution, but other declarative config could be possible for browser-based ES Module Loaders. Examples of useful declarative config in this area are the problems solved via common AMD loader config

So it will be common in JS code to use string IDs, and not URLs to refer to dependency resources.

With the coming of web components and custom elements, it will be possible for a custom element to depend on other custom e

domenic

This is an initial attempt at gathering together up to date resources on ES6 modules.

• The ES6 draft spec has an up-to-date grammar and list of early errors. It's not the easiest thing to read, but is the most authoritative.
• This informal grammar summary is pretty good, and starts to explain how default exports work.
• These two comments in sequence give examples of all the import and export forms available.
• jorendorff/js-loaders is a polyfill for the module loader API and pipeline, and is where current work is taking place.
• This essay is out of date in many ways, but I believe its explanation of the loader pipeline is still more or less accurate. To be sure you'd have to check it agai

ericf

Proposal for Extending Express Apps

Creating npm packages which extend the functionality of Express apps has become a major thing we've been doing. There are several approaches we can take, from messing with the Express object prototypes, to creating a function in which an express app is passed in. After trying the former, I'm now a fan of the latter.

The Issues with Extending Express

Extending the Express object prototypes has issues. The running Node.js process may have multiple versions of express, and in order to extend the prototypes you need to require('express'). This means that you might get a different express module instance than the one the main app is created from.

Both approaches suffer from extending something more than once. Similar to how there may be multiple version of express in the running Node.js process, there can also be multiple copies of the extension modules. If the app developer needs to rely on a different version of an Express ext