Is there any way to run ES6 in Node REPL (Read Evaluate Print Loop)? While running ES 6 commands, I am getting error as shown in the screenshot. Appreciate if someone can help me to configure Node to run ES6 code.
TL;DR: Upgrade Node
I have Node.js v6.0.0, which means I have all the ES6 features unlocked by default. My REPL has support for (basically) everything. Now, node v6.0.0 is currently in development, so you might not want to upgrade your production server, but if you're a developer, it's really stable enough for everyday use.
If you must use an outdated version of node, I would suggest you install n. It's a way to manage your versions of node on one machine.
Good Luck!
Node 4 and higher supports most ES6 features out of the box, here is compatibility table.
To use ES6 features in older Node versions, it should be started with --harmony flag, and code should run in strict mode.
It is not possible to enable strict mode with 'use strict' for REPL globally, so ES6 code should be placed inside IIFE.
Strict mode can be enabled globally with --use_strict. To enable experimental ES6 support in REPL in older Node versions (0.12.x and lower) it should be started with
node --harmony --use_strict
Add 'use strict'.
Strict Mode is a new feature in ECMAScript 5 that allows you to place a program, or a function, in a "strict" operating context. This strict context prevents certain actions from being taken and throws more exceptions.
more information about use strict is here or here
Related
I am a starter in react and ES6. I started with the boilerplate "https://github.com/kriasoft/react-static-boilerplate"
As mentioned in the docs, i Did npm install->node run. But I am getting an error
as "Block-scoped declaration(let, const, hunciton, class) not yet supported outside strict mode."
I tried to put "use strict" at top of the run file, but shows another error "process.argv.includes is not a function"
I am using node version : 4.3.0, npm : 4.0.2. Does this cause the issue.
Do the version matter to support the es6 variables or is this any other issue.
Thanks.
node v4.x uses an older version of V8 (4.5) which did not fully support all scenarios for block-scoped variable declarations in sloppy (non-strict) mode. If you upgrade to a newer version of node, such as node v6.x, you won't have a problem because of the newer version of V8 used there (5.1).
Similarly, Array.prototype.includes was available behind a flag (--harmony_array_includes) in older versions of V8 (including the version used in node v4.x). However, since node v6.x, you can use it without a harmony flag.
For more ECMAScript compatibility information, check http://node.green.
I've been looking all over the Internet without a clear answer for this.
Currently Node.js uses only CommonJS syntax to load modules, and if you really want to use the standard ECMAScript 2015 modules syntax, you either have to transpile it beforehand or use an external module loader at runtime.
Currently I'm not too positive to use either of those two methods, are the Node.js maintainers even planning to support ECMAScript 2015 modules or not? I haven't found an hint at all about this.
At the moment Node.js 6.x claims to support 96% of the ECMAScript 2015 features, but there isn't any reference to modules (Node.js ECMAScript 2015 support link).
Do you know if Node.js will support these modules out of the box, in the near future?
Node.js 13.2.0 & Above
Node.js 13.2.0 now supports ES Modules without a flag 🎉. However, the implementation is still marked as experimental so use in production with caution.
To enable ECMAScript module (ESM) support in 13.2.0, add the following to your package.json:
{
"type": "module"
}
All .js, .mjs (or files without an extension) will be treated as ESM.
There are a number of different options other than entire package.json opt-in, all of which are detailed in the documentation for 13.2.0.
Node.js 13.1.0 & Below
Those still using older versions of Node may want to try the [esm][3] module loader, which is a production-ready implementation of the ES Modules Specificaiton for Node.js:
node -r esm main.js
Detailed Updates...
23 April 2019
A PR recently landed to change the way ECMAScript modules are detected:
https://github.com/nodejs/node/pull/26745
It's still behind the --experimental-modules flag, but there are major changes in the way modules can be loaded:
package.type which can be either module or commonjs
type: "commonjs":
.js is parsed as CommonJS
the default for an entry point without an extension is CommonJS
type: "module":
.js is parsed as an ECMAScript module
does not support loading JSON or a native module by default
the default for an entry point without an extension is ECMAScript module
--type=[mode] to let you set the type on entry point. Will override package.type for entry point.
A new file extension .cjs.
this is specifically to support importing CommonJS in the module mode.
this is only in the ECMAScript module loader, the CommonJS loader remains untouched, but the extension will work in the old loader if you use the full file path.
--es-module-specifier-resolution=[type]
options are explicit (default) and node
by default our loader will not allow for optional extensions in the import, the path for a module must include the extension if there is one
by default our loader will not allow for importing directories that have an index file
developers can use --es-module-specifier-resolution=node to enable the CommonJS specifier resolution algorithm
This is not a “feature”, but rather an implementation for experimentation. It is expected to change before the flag is removed
--experimental-json-loader
the only way to import JSON when "type": "module"
when enable all import 'thing.json' will go through the experimental loader independent of mode
based on whatwg/html#4315
You can use package.main to set an entry point for a module
the file extensions used in main will be resolved based on the type of the module
17 January 2019
Node.js 11.6.0 still lists ES Modules as experimental, behind a flag.
13 September 2017
Node.js 8.5.0 has been released with support for mjs files behind a flag:
node --experimental-modules index.mjs
The plan for this is to remove the flag for the v10.0 LTS release.
--Outdated Information. Kept here for historical purposes--
8 September 2017
The Node.js master branch has been updated with initial support for ESM modules:
https://github.com/nodejs/node/commit/c8a389e19f172edbada83f59944cad7cc802d9d5
This should be available in the latest nightly (this can be installed via nvm to run alongside your existing install):
https://nodejs.org/download/nightly/
And enabled behind the --experimental-modules flag:
package.json
{
"name": "testing-mjs",
"version": "1.0.0",
"description": "",
"main": "index.mjs" <-- Set this to be an mjs file
}
Then run:
node --experimental-modules .
February 2017:
An Update on ES6 Modules in Node.js
The Node.js guys have decided that the least bad solution is to use the .mjs file extension. The takeaway from this is:
In other words, given two files foo.js and bar.mjs , using import * from 'foo' will treat foo.js as CommonJS while import * from 'bar'
will treat bar.mjs as an ES6 Module
And as for timelines...
At the current point in time, there are still a number of
specification and implementation issues that need to happen on the ES6
and Virtual Machine side of things before Node.js can even begin
working up a supportable implementation of ES6 modules. Work is in
progress but it is going to take some time — We’re currently looking
at around a year at least.
October 2016:
One of the developers on Node.js recently attended a TC-39 meeting and wrote up a superb article on the blockers to implementing for Node.js:
Node.js, TC-39, and Modules
The basic take-away from that is:
ECMAScript modules are statically analyzed, and CommonJS are evaluated
CommonJS modules allow for monkey-patching exports, and ECMAScript modules currently do not
It's difficult to detect what is an ECMAScript module and what is CommonJS without some form of user input, but they are trying.
*.mjs seems the most likely solution, unless they can accurately detect an ECMAScript module without user-input
-- Original Answer --
This has been a hot potato for quite some time. The bottom line is that yes, Node.js will eventually support the ES2015 syntax for importing/exporting modules - most likely when the specification for loading modules is finalized and agreed upon.
Here is a good overview of what's holding Node.js up. Essentially, they need to make sure that the new specification works for Node.js which is primarily conditional, synchronous loading and also HTML which is primarily asynchronous.
Nobody knows for sure right now, but I imagine Node.js will support import/export for static loading, in addition to the new System.import for dynamic loading - while still keeping require for legacy code.
Here's a few proposals on how Node might achieve this:
In defense of .js
.mjs modules
I enabled ECMAScript 6 on WebStorm so that I do not get IDE errors when using arrow functions.
However, I did not install Babel. I was prompted to install Babel after enabling ECMAScript 6. I had problems installing Babel.
Is it necessary to use Babel together with ECMAScript 6? What would be the side effect of enabling ECMAScript 6 without installing Babel?
I am using node.js on WebStorm.
The purposes of Babel is to convert es6 code into es5 code BECAUSE most browsers do not FULLY support es6 yet, although are getting closer.
https://kangax.github.io/compat-table/es6/
You will see that IE11 support is poor whilst Firefox and Chrome almost have full support.
However, given that the latest Node fully understands ES6 there is now no need for Babel when using Node only unless of course you need to support older versions of Node which only understand ES5.
PS: if you enable Babel support in Webstorm it can generate ES5 files on the fly for you as you code in ES6. Alternatively, you can use a task runner such as Grunt or Gulp to do this for you. Depends if you need it!
Finally es6 classes have landed in Node.js v4.0.0. But the feature needs --use_strict option to be passed. e.g.
node --use_strict sampleClass.js
What does this --use_strict option signify? Has it anything to do with "use strict"; javascript directive.
Note: On Linux Classes worked in v0.12 too but not in Windows
Edit: If you want to omit --use_strict flag than use "use strict"; in js file
Well, JS has a strict mode which slightly changes how scoping works as well as other small things. Generally, it should be preferred since the bodies of classes and modules are always in strict mode anyway.
Classes work both in strict and loose mode. However, the JavaScript engine Node runs only supports running classes in strict mode at the moment.
This is a limitation of V8 (the engine) and will be resolved in the future. Here is the bug tracking it.
Starting from version 6, classes in NodeJS just work, so no --use_strict flag is required.
What would be the best way to test Harmony features with Jasmine? Jasmine doesn't currently run my tests as it is puzzled by the yields and * symbols.
You'll have to manually run jasmine like this:
node --harmony ./node_modules/jasmine-node/bin/jasmine-node ./spec
You have to run your tests in an environment that supports Harmony features. Check out the ECMAScript 6 compatibility table for an overview of which features are supported in which browsers.
Even if your environment supports some of the new features, there's no guarantee that they conform to specifications. Make sure you read both the vendor documentation and the standard specification so you know what to expect.