Mithril.js: ospec: make bin work for old node version

[futurist]

Expected Behavior

Ospec command line should work with old node version, like 0.12

Current Behavior

$ nvm use 0.12
$ ./node_modules/.bin/ospec

It will throw

const o = require("../ospec")
^^^^^
SyntaxError: Use of const in strict mode.

It's totally ES6, which is not work in old node.

Possible Solution

Transpile the ES6 to ES5.

Your Environment

• Version used: node 0.12
• Browser Name and version:
• Operating System and version (desktop or mobile):
• Link to your project:

[pygy]

@futurist thanks for the report.

As much as I care about ES5 compat for Mithril itself, I'm not sure it is worth it to pursue backwards compat on the Node side.

For legacy projects, you can keep on using legacy ospec, and for greenfield projects, I can't see why you'd want to use a pre v4 Node... Are you using nvm in your test suite? For Travis?

See ES6 support per version and Node download stats per version.

Edit: I just realized we hadn't mentioned the old Node version deprecation in the change log. Sorry for the bad surprise.

[futurist]

Yes, for travis, and the project for testing is already transpiled to ES5, and run an old node version to check whether it's ES5 compatible.

[barneycarroll]

@futurist you could use eslint to guard against use of JavaScript features. For my library Patchinko I use ES6 tests to assert functionality and eslint to assert ECMAScript 3 compliance (It's failing on Travis but I'm pretty sure it's unrelated to the eslint proposition). This is more robust & pragmatic IMO: you don't restrict every aspect of your development environment and pipeline, but you're also able to give more concrete assurances than 'works on Node 0.12', which can be validated against other environments.

[pygy]

I think that @futurist wants to run the test suite in an ES5-only environment.

If we ever introduce a transpiling step let it be for TypeScript in strict mode (no implicit any), not for the basic features we're using here (const, let and arrow functions, but only for readability, we don't even rely on the lexical scoping of this and let bindings).

So I'm not against going back to ES5 in ospec/bin/ospec.js.

[futurist]

thanks! can you publish a version to npm?

[pygy]

Soon. I'll push a couple of other fixes and publish 2.1 today.

[pygy]

@futurist [email protected] is out

The other changes are more involved than I anticipated, they'll come with 2.1.1 or 2.2.0.