Tag Archives: ES6

Node, MVC Controllers and ECMAScript 2015


Long time readers of my blog will remember that I previously covered Node and MVC applications in a short tutorial series. At that point, I wrote the controllers and loader in ECMAScript 5.1. The code to load the controllers was this: The typical controller looked like this: That’s a lot of boilerplate code and it’s […]

http://shellmonger.com/2015/07/30/node-mvc-controllers-and-ecmascript-2015/

How to write unit tests for ES6 code using NodeJS & Traceur


How to write unit tests for ES6 code using NodeJS & Traceur
ES6 is coming… Some of you may have heard about ES6 (ECMAScript 6), the next version of the ECMAScript language specifications. If you’re a web developer and haven’t heard about this, then it’s time to wake up and get some read on the Internet about it, cause it will revolutionize the way you write JavaScript, whether it’s for […]

Turn ES6 code into readable vanilla ES5 with source maps


benchmark fix lint errors 14 days ago
bin fix canCompile in readdirFilter in bin/6to5 util 2 days ago
lib/6to5 change useless self references to this 9 hours ago
test change test-appveyor to test-spec and add test-clean method to clean … 11 hours ago
.editorconfig first commit a month ago
.gitignore rename browserified polyfill to browser-polyfill – fixes #140 21 hours ago
.jshintignore fix lint errors a month ago
.jshintrc fix linting errors 8 days ago
.npmignore change behaviour of tests and browser testing/build 8 days ago
.travis.yml change gitter travis hook to always 2 days ago
CHANGELOG.md add 1.12.1 changelog 9 hours ago
FEATURES.md add async functions to features 9 hours ago
LICENSE first commit a month ago
MODULES.md add example usage for custom module formatters 9 days ago
Makefile change test-appveyor to test-spec and add test-clean method to clean … 11 hours ago
README.md add async functions to features 9 hours ago
appveyor.yml change test-appveyor to test-spec and add test-clean method to clean … 11 hours ago
package.json v1.12.1 10 hours ago
polyfill.js rename browserified polyfill to browser-polyfill – fixes #140 21 hours ago
register.js implement custom require ignore regex – closes #72 28 days ago

6to5

6to5 turns ES6 code into vanilla ES5, so you can use ES6 features today.

  • Readable – formatting is retained if possible so your generated code is as similar as possible.
  • Extensible – with a large range of plugins and browser support.
  • Losslesssource map support so you can debug your compiled code with ease.
  • Compact – maps directly to the equivalent ES5 with no runtime*.

Installation

It’s as easy as:

$ npm install -g 6to5

Table of Contents

Features

Usage

Plugins

CLI

Compile the file script.js and output it to stdout.

$ 6to5 script.js

Compile the file script.js and output it to script-compiled.js.

$ 6to5 script.js --out-file script-compiled.js

Compile the file script.js and output it to script-compiled.js and save a source map to script-compiled.js.map.

$ 6to5 script.js --source-maps --out-file script-compiled.js

Compile the file script.js and output it to script-compiled.js with a source map embedded in a comment at the bottom.

$ 6to5 script.js --source-maps-inline --out-file script-compiled.js

Compile the entire src directory and output it to the lib directory.

$ 6to5 src --out-dir lib

Compile the entire src directory and output it to the one concatenated file.

$ 6to5 src --out-file script-compiled.js

Pipe a file in via stdin and output it to script-compiled.js

$ 6to5 --out-file script-compiled.js < script.js

Node

Launch a repl.

$ 6to5-node

Evaluate code.

$ 6to5-node -e "class Test { }"

Compile and run test.js.

$ 6to5-node test

Node

var to5 = require("6to5");

var result = to5.transform("code();", options);
result.code;
result.map;
result.ast;

to5.transformFileSync("filename.js", options).code;

to5.transformFile("filename.js", options, function (err, result) {

});
Options
{
  // Filename for use in errors etc.
  // Default: "unknown"
  filename: "filename",

  // List of transformers to EXCLUDE.
  // Run `6to5 --help` to see a full list of transformers.
  blacklist: [],

  // List of transformers to ONLY use.
  // Run `6to5 --help` to see a full list of transformers.
  whitelist: [],

  // Module formatter to use
  // Run `6to5 --help` to see a full list of module formatters.
  // Default: "common"
  modules: "common",

  // If truthy, adds a `map` property to returned output.
  // If set to "inline", a comment with a sourceMappingURL directive is added to
  // the bottom of the returned code.
  // Default: false
  sourceMap: true,

  // Set `file` on returned source map.
  // Default: `filename` option.
  sourceMapName: "filename",

  // Set `sources[0]` on returned source map.
  // Default: `filename` option.
  sourceFileName: "filename",

  // Optionally replace all 6to5 helper declarations with a referenece to this
  // variable. If set to `true` then the default namespace is used "to5Runtime".
  // Default: false
  runtime: true
}

Require hook

All subsequent files required by node with the extensions .es6 and .js will be transformed by 6to5. The polyfill specified in Polyfill is also required.

require("6to5/register");

NOTE: By default all requires to node_modules will be ignored. You can override this by passing an ignore regex via:

require("6to5/register")({
  // This will override `node_modules` ignoring - you can alternatively pass
  // a regex
  ignore: false
});
Options
require("6to5/register")({
  // Optional ignore regex - if any filenames **do** match this regex then they
  // aren't compiled
  ignore: /regex/,

  // Optional only regex - if any filenames **don't** match this regex then they
  // aren't compiled
  only: /my_es6_folder/,

  // See options above for usage
  whitelist: [],
  blacklist: [],

  // This will remove the currently hooked extensions of .es6 and .js so you'll
  // have to add them back if you want them to be used again.
  extensions: [".js", ".es6"]
});

Browser

A browser version of 6to5 is available from browser.js inside the 6to5 directory in an npm release.

Scripts

While it’s not recommended for serious use, when the browser version is included all scripts with the typetext/ecmascript-6 and text/6to5 are automatically compiled and ran.

For example:

<script src="node_modules/6to5/browser.js"></script>
<script type="text/6to5">
class Test {
  test() {
    return "test";
  }
}

var test = new Test;
test.test();
</script>

Build

You can build a browser version of the compiler by running the following in the 6to5 directory:

$ make build

This will output the files dist/6to5.js and dist/6to5.min.js.

API

to5.transform("class Test {}").code;

Test

To test 6to5 in your browser run:

$ make test-browser

And open test/browser.html in your browser if it doesn’t open automatically.

Modules

See Modules – Common for documentation on the default module formatting.

Alternatively see Modules for all other supported module formatting types.

Caveats

For-of

A polyfill is required for for-of functionality that implements Symbol and addsprototype[Symbol.iterator] behaviour to built-ins. Using the polyfills specified in polyfill suffices.

Classes

Built-in classes such as Date, Array and DOM cannot be subclassed due to limitations in ES5 implementations.

If you’re inheriting from a class then static properties are inherited from it via __proto__, this is widely supported but you may run into problems with much older browsers.

NOTE: __proto__ is not supported on IE <= 9 so static properties will not be inherited. A possible workaround is to use super();:

class Foo {
  static foo() {

  }
}

class Bar extends Foo {
  static foo() {
    super();
  }
}

Generators

The regenerator runtime and an ES6 polyfill are required in order for generators to work.

Polyfill

6to5 includes a polyfill that includes the regenerator runtime and the es6-shim and es6-symbol polyfills.

Node

require("6to5/polyfill");

Browser

Available from the browser-polyfill.js file within the 6to5 directory of an npm release.

Optional runtime

6to5 has a few helper functions that’ll be placed at the top of the generated code if needed so it’s not inlined multiple times throughout that file. This may become an issue if you have multiple files, especially when you’re sending them to the browser. gzip alleviates most of this concern but it’s still not ideal.

You can tell 6to5 to not place any declarations at the top of your files and instead just point them to a reference contained within the runtime.

Simply use the following option if you’re using the Node API:

{
  runtime: true
}

or the following flag if you’re using the CLI:

$ 6to5 --runtime

Then just include the runtime before your generated code.

Getting the runtime

You can get the runtime via either:

$ 6to5-runtime

or

require("6to5").runtime();

or from an npm release in runtime.js from the 6to5 directory.

Customising namespace

You can also customise the runtime namespace by passing an optional namespace argument:

require("6to5").runtime("myCustomNamespace");
$ 6to5-runtime myCustomNamespace

See Options – runtime for documentation on changing the reference in generated code.

React/JSX

6to5 has built-in support for React v0.12. Tags are automatically transformed to their equivalentReact.createElement(...) and displayName is automatically inferred and added to allReact.createClass calls.

To disable this behaviour add react to your blacklist.

Differences

Philosophy

The fundamental concept behind 6to5 is that the generated code must be close as possible to the original, retaining all the same formatting and readability.

Many other transpilers are just concerned with making the code work while 6to5 is concerned with making sure it works and is readable at the same time.

For example, given the following array comprehension:

var seattlers = [for (c of customers) if (c.city == "Seattle") { name: c.name, age: c.age }];

is generated to the following with 6to5:

var seattlers = customers.filter(function (c) {
  return c.city == "Seattle";
}).map(function (c) {
  return {
    name: c.name,
    age: c.age
  };
});

The following is what Traceur generates:

var seattlers = (function() {
  var c;
  var $__20 = 0,
      $__21 = [];
  for (var $__22 = customers[$traceurRuntime.toProperty(Symbol.iterator)](),
      $__23; !($__23 = $__22.next()).done; ) {
    c = $__23.value;
    if (c.city == "Seattle")
      $traceurRuntime.setProperty($__21, $__20++, {
        name: c.name,
        age: c.age
      });
  }
  return $__21;
}());

As you can tell, it’s not very pretty, unreadable even. Instead of mapping directly to a runtime, like other transpilers, 6to5 maps directly to the equivalent ES5.

I’m not saying 6to5 is for everyone or even suited for everything. Traceur is better suited if you’d like a full ES6 environment with polyfills and all.

Comparison to other transpilers

6to5 Traceur esnext es6now es6-transpiler jstransform
No runtime
Source maps
No compiler global pollution
Arrow functions
Classes
Computed property names
Constants
Default parameters
Destructuring
For-of
Generators
Let scoping
Modules
Property method assignment
Property name shorthand
Rest parameters
Spread
Template literals
Unicode regex

Traceur

Traceur requires quite a bulky runtime (~75KB) and produces quite verbose code. While this can be trimmed down by selectively building the runtime, it’s an unneccesary step when a runtime can be eliminated entirely.

es6now

es6now doesn’t output sourcemaps. This is cited as a positive as line-to-line mapping is the goal. This however obviously doesn’t retain column mapping resulting in the output code not being very pleasant.

es6-transpiler

The es6-transpiler compiler requires shims to operate which pollutes the global scope resulting in possible collisions.

es6-transpiler maps line-by-line, just like es6now, this results in the same issues such as lack of column information and unpleasant code output.

Transit for JavaScript


README.md

transit-js

Transit is a data format and a set of libraries for conveying values between applications written in different languages. This library provides support for marshalling Transit data to/from JavaScript. transit-js will work with any ECMAScript-262 Edition 3 or newer JavaScript implementation provided that a JSON module that supplies parse and stringify methods is present. transit-js does not currently support encoding toMessagePack.

This implementation’s major.minor version number corresponds to the version of the Transit specification it supports.

NOTE: Transit is a work in progress and may evolve based on feedback. As a result, while Transit is a great option for transferring data between applications, it should not yet be used for storing data durably over time. This recommendation will change when the specification is complete.

Releases and Dependency Information

JavaScript

You can include either the release (10K gzipped) or development build of transit-js on your webpage. We also provide Require.js compatible release and dev builds.

Node.js

transit-js is released to npm. Add transit-js to your package.json dependencies:

{...
  "dependencies": {
    "transit-js": "0.8.746"
  }
 ...}

Bower

You can also include transit-js in your bower.json dependencies:

{...
  "dependencies": {
    "transit-js": "0.8.746"
  }
 ...}

Maven

Maven dependency information:

<dependency>
  <groupId>com.cognitect</groupId>
  <artifactId>transit-js</artifactId>
  <version>0.8.746</version>
</dependency>

Documentation

Comprehensive documentation can be found here.

Overview

transit-js supports the conveyance of semantically rich and extensible data between heterogenous software systems whose components include JavaScript servers and clients.

Beyond JSON

The Transit rationale covers many of the reasons to put aside the limitations of JSON. As with the other Transit implementations, transit-js supports conveying a larger range of scalar and non-scalar values than permitted by JSON. Of these types, the transit-js handling of the map representation is the most novel from the perspective of a JavaScript applications developer.

Transit Maps

Transit representations of maps are decoded by transit-js into a high performance data structure that largely mirrors the ECMAScript Edition 6 Map data type. Doing so allows natural indexing of data using common scalars like 64 bit integers and dates without requiring the out of band application logic often encountered in systems that marshal JSON.

The adaptive implementation of transit-js maps delivers performance comparable to plain JavaScript objects and native ES6 Map implementations.

Usage

Please see the Getting Started page. For an interactive guide check out the tour.

From the browser transit-js is available at the top level:

var t = transit;

function roundtrip(x) {
  var r = t.reader("json"),
      w = t.writer("json");
  return r.read(w.write(x));
}

function testRoundtrip() {
  var arr1 = ["red", "green", "blue"],
      arr2 = ["apple", "pear", "grape"],
      data = t.map();
  data.set(t.integer(1), arr1);
  data.set(t.integer(2), arr2);
  return t.equals(data, roundtrip(data));
}

From Node.js you must require transit-js (assuming you’ve included it in your project dependencies):

var t = require("transit-js");

function roundtrip(x) {
  var r = t.reader("json"),
      w = t.writer("json");
  return r.read(w.write(x));
}

function testRoundtrip() {
  var arr1 = ["red", "green", "blue"],
      arr2 = ["apple", "pear", "grape"],
      data = t.map();
  data.set(t.integer(1), arr1);
  data.set(t.integer(2), arr2);
  return t.equals(data, roundtrip(data));
}

Default Type Mapping

Abbreviations:

  • t = transit
Transit type Write accepts Read returns
null null null
string String String
boolean Boolean Boolean
integer Number, t.integer Number, t.integer
decimal Number Number
keyword t.keyword t.keyword
symbol t.symbol t.symbol
big integer t.bigInt t.bigInt
big decimal t.bigDec t.bigDec
bytes Buffer, Uint8Array, t.tagged Buffer, Uint8Array, t.tagged
time Date Date
uri t.uri t.uri
uuid t.uuid t.uuid
char String String
array Array Array
set t.set t.set
map t.map t.map
link t.link t.link
cmap t.map t.map

Contributing

This library is open source, developed internally by Cognitect. We welcome discussions of potential problems and enhancement suggestions on the transit-format mailing list. Issues can be filed using GitHubissues for this project. Because transit is incorporated into products and client projects, we prefer to do development internally and are not accepting pull requests or patches.

Development

Dependencies

Building and testing transit-js requires Node.js. Install the project’s additional development dependencies with the following command from the repo directory:

bin/deps

In order to build transit-js for ClojureScript, Maven must be installed.

Running the tests

bin/test

In order to run the bin/verify tests from transit-clj, you must first build the production Node.js build:

bin/build_release_node

Build

Version

The build version is automatically incremented. To determine the current build version:

build/revision

Build for Node.js

bin/build_release_node

Build for Browser

bin/build_release_browser

Building the documentaiton

bin/docs

Build JAR for ClojureScript

Assuming you have a JDK and Maven installed, the following will install a JAR suitable for use from ClojureScript into your local Maven repository.

build/package_local

Copyright and License

Copyright © 2014 Cognitect

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

ES6 in Angular 2.0


In this talk, Erik explains what additional features of ES6 will be used in Angular 2.0 and how they’ll work with Traceur.

“Virtual Machines, JavaScript and Assembler” Keynote


How does the pervasiveness of JavaScript on the client change how we architect applications? We can create hundreds virtual machines in the cloud, but we are using the millions of visual machines that visit our sites every day?

Suddenly we are scripting against thousands of Virtual Machines from the command line while creating things today with JavaScript in the browser that were impossible yesterday. LiveScript becomes JavaScript becomes ES6 and now we’re compiling C++ to JavaScript.

Learning ES6 as a Community


The current schedule for the completion of ECMAScript 6, the next version of JavaScript, dictates that the language specification be finished by the end of the second quarter of 2014. Most browser vendors have made informal commitments to have ES6 implemented by the end of the year. Over the last couple years, we’ve heard a lot about the many new features in ES6, along with the debate (and bickering) which has gone into its design. ES6 stands to be the most substantial change to JavaScript since ES4 (which didn’t work out that great, as most users of ES5 are aware).

With this much change comes a lot of complexity. Many of the new features (like generators or proxies) are powerful, basic abstractions, and as such combine in complex (and potentially unexpected) ways. In many ways, a new version of JavaScript offers the possibility of returning us to the wild frontier days that JavaScript only recently left behind, with library and framework vendors each choosing their own combinations of features to build powerful (and complicated) architectures that can really only be understood on their own terms.

However, as a community we’ve learned a lot over the last half decade or so, and I think we’ve learned how to tackle this problem head on. I’ve come up with a strategy that I think would allow us to collaboratively get to a good place with ES6 relatively quickly. I’ll go over this strategy and point to the areas where I think we ought to spend the most time to get the most positive results.

It’s up to us — as a community of designers, developers, and implementors — to get out in front and provide tooling, documentation, and training that will help ourselves use these new features effectively, before folklore and superstition start to take root. And it’s important to remember that finishing ES6 frees the JavaScript standards bodies to concentrate on ES7, where our feedback from using ES6 will help them refine what comes next.