Node.JS v0.11.3 claims to have support for ECMAScript 6 modules with the flag --harmony_modules.
I have tried various examples, such as the following.
module math {
export var pi = 3.141593;
}
What is the syntax to get modules working in Node.JS?
The modules implementation in V8 is incomplete. There's parsing support when enabled with --harmony-modules, but support of the actual functionality was put on hold. The reason for this is because the specification for how ES6 modules will actually work has been in the works and is still not fully nailed down.
The implementation in Continuum (the linked screenshot from Crazy Train's answer) dates back to an interim spec from November 2012 and is now woefully out of date because of the ongoing changes to the ES6 module's spec. This is why the V8 devs put development of support for modules on hold.
It seems like the modules spec is approaching stability (though I expect we'll see small refinements for a while) and I think (hope at least) that we'll see SpiderMonkey and V8 moving forward with implementations over the next 6 months.
Useful links:
V8 modules bug: https://code.google.com/p/v8/issues/detail?id=1569
SpiderMonkey modules bug: https://bugzilla.mozilla.org/show_bug.cgi?id=harmony%3Amodules
You can use Continuum, which is an ES6 virtual machine written in (current) JavaScript.
Related
TypeScript supports Node's ECMAScript module resolution with the node16 and nodenext module and moduleResolution options. It's not clear if I must use Node 16 or greater to use either option. Node 14 has support for ESM and not much changed between 14 and 16. Experimentally TypeScript works as expected with Node 14 and node16 but maybe there are edge cases that I'm not aware of.
https://www.typescriptlang.org/docs/handbook/esm-node.html
The 16.0.0 change log lists a few removals and deprecations but no new features or changes to module resolution. I don't think these changes would affect typescript.
(SEMVER-MAJOR) module: remove module.createRequireFromPath (Antoine du Hamel) #37201
(SEMVER-MAJOR) module: runtime deprecate subpath folder mappings (Antoine du Hamel) #37215
(SEMVER-MAJOR) module: runtime deprecate "main" index and extension lookups (Antoine du Hamel) #37206
(SEMVER-MAJOR) module: runtime deprecate invalid package.json main entries (Antoine du Hamel) #37204
(SEMVER-MAJOR) process: runtime deprecate changing process.config (James M Snell) #36902
Regarding features support, you can take a look at this matrix to verify that what you need works as expected. Regarding module support when you take a look at the documentation of NodeJS, some New features have been added like in V16.17 but it seems that compatibility is an important matter; moreover a breaking change would be indeed in the logs like the ones you mentionned above. Node 16.17 is a LTS so stability is of greater concern than intermediates. Hope that helps !
When I first saw this question, I thought this was a simple "yes, you need to use Node 16 with this." After doing initial research, that answer became foggy, but after lookin gat this SO post, it again seems that you need to use Node 16 with node16 and nodenext.
Node 14 has support for ESM and not much has changed between 14 and 16.
I believe that since they have added that support, patches pushed for Node 10 and 12 have also allowed support for it, so that may change they way we approach this question.
In the end, I still believe that using Node 16 is the best option for you.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am looking to working on a project using node js addons with C++. I came across two abstract library NAN and N-API that I can use. However I am unable to decide which one I should use. I was not able to find proper comparison between these two libraries.
What are the pros, cons and differences of both? How to choose between them?
So far I have found that NAN has more online tutorials/articles regarding async calls. But N-API is officially supported by Node (and was created after NAN as a better alternative, although not sure.)
My understanding is this:
The Node-API (formerly N-API) was added to the core node.js interface in v8.0.0. "It is intended to insulate Addons from changes in the underlying JavaScript engine…" to quote the documentation. It also provides some other wrappers around things like buffers and asynchronous work (which should help avoid some of the underlying non-stable APIs noted in their Implications of ABI stability section).
nan (Native Abstractions for Node) is indeed older and so also supports older versions of node.js — back to node.js 0.8! Now despite its author claiming back in 2017:
As I mentioned somewhere else, N-API is not meant to be directly used for anything. Where has this notion come from? It is an (effectively internal) low-level infrastructure layer meant to offer ABI stability. There will be another layer on top.
…I do not see much warning to that effect in the official Node.js add-on documentation. Perhaps this other comment is a bit more insightful:
Yes, you should still use NAN for production use. It covers every relevant version of Node.js. Also note that N-API is not intended for end users. You should eventually use https://github.com/nodejs/node-addon-api.
Again, that was in June of 2017 by the maintainer of nan at the time. It seems that node-addon-api has matured in the meantime and remains active. In fact, I found a comment in the -addon-api repo that is only a month old at present:
…part of the goal was to make it easy to transition from nan.
So I think the answer is:
use nan if you want something mature and very backwards-compatible
use node-addon-api if you want something forwards-looking in C++
use Node-API/N-API if you are comfortable working in C and dealing with possible lower-level concerns
You should use the node-addon-API module for new C++ code (or N-API for C code). All supported (non-EOL) versions of Node.js support it, and it makes maintaining and distributing native add-ons much easier: whereas addons using NAN require rebuilding the module for each NODE_MODULE_VERSION (major version of Node.js), modules using N-API/Node-Addon-API are forward-compatible:
A given version n of N-API will be available in the major version of Node.js in which it was published, and in all subsequent versions of Node.js, including subsequent major versions.
There's a somewhat confusing compatibility matrix here. N-API version 3 is compatible with Node.js v8.11.2+, v9.11.0+ and all later major versions (v10+), for example.
On top of that, node-addon-API fixes a lot of the annoying parts of NAN (like Buffers always being char* instead of, say uint8_t*).
NAN still works of course, and there are more learning resources online, but node-addon-API is the way forward.
This question already has an answer here:
Node.js plans to support import/export ES6 (ECMAScript 2015) modules
(1 answer)
Closed 5 years ago.
Just wonder how do we import a module in node.js 8 - are we still using require?
Or do we still need babel for using import?
I have been digging around but seems no answer. If we still have to use require, why can't node implement import yet?
UPDATE-2018.11.15 ↓
Short answer
We're still using require
Long answer
ESM loading has partially landed in node 8.5.0 which was released in September 2017. As such, it has beeen part of the specs as an experimental feature for a little while: see the API documentation here. Caveats include the need for the --experimental-modules flag and the use of a new .mjs extension for modules.
There is still changes that need to happen in V8 before ESM loading is stable and fully featured so as with my original answer, I would still advise on sticking with CommonJS require if you don't already use Babel for other stuff
See this post for a more didactic explanation
PREVIOUS ANSWER ↓
The two implementations are completely different under the hood, so there is more to it than what meets the eyes
The takeaway is that there are still lingering issues/questions over the specifications (all the way to V8), and as such import cannot currently be implemented in Node without a using a transpiler
See this comment (dated February 2017) from one of the contributor:
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.
Keep in mind that transpilers simply converts the ES6 module syntax to the CommonJS module syntax, so there is currently no performance benefits. In other words, if you don't have a Babel pipeline already, there is not much incentives to create one just to use the new proposed import syntax, except from a proactive syntactic perspective
For more details on how the implementation differs, see this write up
As part of a major refactoring of my Node.js app (going DDD), I'm looking for a library that through inspecting code is able to visualize module dependencies (by means of 'requiring' them) between different node-modules.
Visualizing in Table-format is fine, I don't need fancy graphs.
Any Node libraries out there?
If you may accept also some fancy graphs: http://hughsk.github.com/colony/
I do not know if this exists, but I found the following by quick search:
http://toolbox.no.de/packages/subdeps
http://toolbox.no.de/packages/fast-detective
Maybe subdeps is not exactly what you want right now, but I think you could use these projects to make that project yourself?
See also https://github.com/pahen/madge
Create graphs from your CommonJS, AMD or ES6 module dependencies. Could also be useful for finding circular dependencies in your code. Tested on Node.js and RequireJS projects. Dependencies are calculated using static code analysis.
I just published my node-dependency-visualizer, which is a small module, that creates a digraph from your node dependencies. Paired with graphviz/dot you can create a dependency graph as svg (or other image format) which you can include with your documentation, embed in your Readme.md, ...
However, it does not check, whether the dependencies are actually needed in code - not sure, whether the OP meant that with "requiring". Of course this question is old, but this tool might be helpful for others, too.
Sample image (Angluar cli):
Here is my test code (to be run using node --harmony-proxies foo.js:
var a = Proxy.create({
get : function (proxy, prop)
{
return 5
}
})
console.log(a['foo'])
console.log(a.length)
console.log(a['10'])
console.log(a[10])
Why the last 2 lines fail to print 5, why the proxy fails to intercept properties looking like integers? Is it an implementation bug or is it how it is specified? Is there a separate way to intercept array indices so I can implement my own arrays (e.g. sparse arrays)?
If I read the node changelogs correctly, then node 0.6.18 is still running on V8 3.6.6, which is a fairly old version (from October 2011). In that version, support for proxies was still work in progress (as the other supported Harmony features). Don't expect proxies to function properly before V8 3.8 (from December 2011). Unfortunately, I cannot tell you when the stable version of node will upgrade beyond that.
As A. Rossberg indicated, that bug (and a couple of other showstoppers) are fixed in V8 3.8 (node 0.7.x is quite stable and 0.8.x nears release). If you're working with proxies though, there's still some bugs that you'll have to watch out for. This github issue has a pretty good quick overview of them: https://github.com/tvcutsem/harmony-reflect/issues/4