I've noticed it in my company's codebase and it has 30M downloads per week so I'm curious about its importance.
regenerator-runtime is the runtime support for compiled/transpiled async functions. (It may well have other uses, but this is the predominant one.)
When you use a compiler like Babel that compiles modern JavaScript into earlier JavaScript (a process sometimes called transpiling), one of the things you can do is compile async functions to something that will run on JavaScript engines that don't support async functions (such as the increasingly-irrelevant IE11). Babel does the syntax transformation, but the resulting code relies on runtime support from regenerator-runtime.
Related
Current Javascript adopts import from ES6 as a standard way to import modules.
However, I sometimes see codes using CommonJS require instead of import.
I first wondered whether two can be used together, but it seems like two are not interchangeable. (releated stackoverflow question)
So, is CommonJS 'require' something that is still used in projects? Or is it slowly dying and needed only for maintaining legacy codes?
CommonJS will likely be supported in nodejs for a long time as there are still millions of lines of code written using it. It is the original module loading mechanism in nodejs. It is not deprecated.
ESM modules (ECMAScript modules) that use import and export are the new Javascript standard for modules and we can expect that nodejs will support these for as long as they are the Javascript standard (probably forever).
These two modules standards are not entirely compatible so mixing and matching within the same project can lead to complications that you have to learn how to deal with.
New Projects
If I were starting a new project today, I'd choose to write my code using ESM modules as it is the future trajectory of the language and nodejs. And, you can still load CommonJS modules into ESM modules if you require backward compatibility with other modules, but you do have to know how to do it properly - it's not always seamless to mix and match module types.
When ESM modules were first supported in nodejs, the interoperability with CommonJS modules was not very full featured and created some difficulties. As of the more recent versions of nodejs, you can load a CommonJS module from an ESM module or vice versa- you just have to use the right techniques to do it. This makes working from an ESM project a lot more feasible now than it was when ESM support in nodejs first came out as you can still access libraries in NPM that only support CommonJS.
Note also that more and more libraries in NPM are supporting direct loading from either module type so they are equally easy to use whether your project is CommonJS or ESM.
Over time, I would expect that any actively developed, shared module on NPM will eventually support direct loading as an ESM module. But, we're in this transition period of time where many have not yet implemented that or there are particular challenges in implementing the new loading scheme (which comes with it's own and different set of rules). In the meantime, you can still load CommonJS modules into ESM projects.
Existing CommonJS Projects
If I had an existing project that was CommonJS, I would not be spending any time thinking about converting it to ESM because there is still widespread support for CommonJS and my developer time is probably better spent on adding features, testing, fixing bugs, etc... than converting module formats.
Interoperability
One of the important interoperability things to know is that you can load a CommonJS module from an ESM module in several different ways:
With a static import: import { callMeCommon } from '../otherProject/common.js';
With a dynamic import import(someFile).then(...)
By using module.createRequire(import.meta.url) and then using that require() function to load your CommonJS module.
You can also use the dynamic import('someModule').then(...) to load an ESM module from a CommonJS module, but it's not synchronous like require() was so it has to be dealt with differently.
It's also useful to know that ESM modules do not have some nodejs niceties that CommonJS modules had. There's no automatic __dirname or __filename to tell you exactly where this file was loaded from. Instead, you have to parse those values out of import.meta.url and compute them. So, it's still possible to get that information, it's just not as convenient as it used to be.
On the other hand, ESM modules have some features like top level await that CommonJS do not which can be very useful.
Your Specific Questions
So, is CommonJS 'require' something that is still used in projects?
Yes, it is still used a lot.
Or is it slowly dying and needed only for maintaining legacy codes?
[Comments as of early 2022] I wouldn't so much say that it is dying as there are very few projects on NPM that don't still support CommonJS. In fact, when a project releases a new version that no longer supports CommonJS, it creates quite a problem for their user base (we see some of these issues here on stackoverflow) because of the significant prevalence of CommonJS projects still and people not familiar with how to load different module types.
So, I'd say that we're still in a very early stages of a transition from CommonJS to ESM and it's more like ESM is getting more and more adoption rather than CommonJS is dying. I'd hazard a guess that the majority of modules on NPM will, over the next few years, move to support direct loading from both module formats.
Transpiling
Lastly, developers often use transpiling to allow them to write code using the newest syntax and features, but using a transpiler to convert the code back to a lower, common denominator that runs anywhere. That can also be done for module architecture (write code in ESM, transpile to CommonJS).
A Few Interesting References
What does it take to support Node.js ESM?
Hybrid npm packages (ESM and CommonJS)
Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
All you need to know to move from CommonJS to ECMAScript Modules (ESM) in Node.js
In Nodejs it doesn't yet appear to be deprecated given the LTS v20 precursor (v19) documentation describes the feature:
https://nodejs.org/api/esm.html#interoperability-with-commonjs
https://github.com/nodejs/Release
If locked into Nodejs the above affords a length of time into 2025 for using LTS Nodejs runtimes, with legacy code, and possibly polyfill the same whenever the Nodejs product changes status (the module system or the whole runtime).
CommonJS is the legacy module system specific to Nodejs
see https://wiki.commonjs.org/wiki/Modules/Meta
Generally outside of Nodejs Commonjs/require has been displaced in JS/TS runtimes by ESModules:
https://developer.mozilla.org/docs/Web/JavaScript/Guide/Modules
As much as possible I've been moving away from Nodejs to Deno and haven't looked at the specifics and details of its npm and Nodejs compatibility. For those who're looking to implement software using contemporary web platform features it's the best forward-looking with current working solutions that I'm aware of (more at https://deno.land/).
import { createRequire } from "https://deno.land/std/node/module.ts";
// import.meta.url...like `__filename` ...
const require = createRequire(import.meta.url);
const path = require("path");
I'm stuck with dynamic requering es6 modules by invoking them through:
System.import('SOME_PATH').then(function (MODULE_FROM_SOME_PATH) {});
It works well with es6-module-loader and babel runtime compilation in browser, but when i want to precompile it to ES5 syntax (for production uses) it just passes System.import expression in code, leaving in practically untouched, just replacing System.import with equivalent System['import'].
I've tried gulp-babel and babel npm package. So when opened in browser it gives expected module loading error. How can i transpile my code to AMD syntax for ES5. Hoping for your help.
Just pushed babel-plugin-system-import-transformer that replaces System.import to the equivalent UMD import (AMD, CommonnJS & Global module imports).
I have also created a separate localforage branch that uses System.import statements as an example.
Hope this helps.
As the ES6 spec is nearing completion, I'm investigating get a jump start on ES6 syntax and leveraging traceur compiler to do so.
My question is that I see that tracuer requires a 'runtime' file to be included on the page, is this a shim for some lacking 'core' features like Array/etc OR is this a runtime converter and then the build is just for deploying?
If its just a 'shim' per say, how do you deal with always compiling during development? I know you could do a watch in grunt but for large applications that seems very slow. I also saw you could use a node compiler, but node is not my backend/server tech ( I use IIS, ya i know ).
Thoughts/suggestions?
Is there any software that I can use to compile nodejs program?
The reason I want to compile nodejs code is to make it safely distributable.
For example for a desktop application,etc.
And also I want to know whether nodejs will execute faster if compiled as it is asynchronous already?
Javascript is not a compiled language and Node.js is Javascript. It will be executed and interpreted at runtime. You can process your javascript with tool like grunt.js for example lint-test and uglify it, but be careful so that do not break the npm system since it is based on certain conventions.
To package your javascript for distribution in the node.js context build an npm module.
https://www.npmjs.org/doc/developers.html
For distributing javascript to the desktop client: Remember it's Javascript an it need to be executed in the Javascript VM. So to have some UI you need to run it in the browser or you need to have some webkit compiled dll to run your code...
something like this...
http://www.tidesdk.org/
You can also use: http://github.com/rogerwang/node-webkit (Thanks to #edi9999)
There is no way to do that with v8, it has only JIT option. It possible to make a "snapshot" with v8, but it's not exactly the same as compilation and node.js doesn't have support for this feature (also it might produce slower code). Also all your code will be available with toString() of functions.
You might be interested in JXcore project. It is a fork of node and as far as I know has some solution to code protection. Also one of the project goals is to develop javascript-to-LLVM compiler. Of course it can't have full support for ES specification (eval, new Function etc).
There's no way to 'compile' a nodejs program, as the javascript is interpreted at run time.
However, if you want to protect your code, you could maybe use something like Uglify JS to make the javascript less readable. However, this won't hinder people to change around your code.
The closest you might get to acheiving your goal is to create a self-executing Javascript bytecode wrapper.
A project that does this is pkg
It somehow creates a self-contained binary executable from Javascript, including module dependencies and asset files and produces a self-contained executable.
Installation and use is easy:
$ npm install -g pkg
$ pkg index.js -o my-program
$ ./my-program
It seems the resulting binary contains nodejs bytecode. It appears that you can cross-compile.
After reading Peter's article on JavaScript I noticed
Brendan Eich stated that one the goals for Harmony is to be a better target for to-JavaScript compilers.
There are currently two popular compilers with some vague ES:Harmony compliance:
Traceur
CoffeeScript
Although CoffeeScript has some compliance it's not designed to be an ES:Harmony compiler so it's not useful to this end.
Tracuer seems to be sticking more rigorously to the ES:Harmony specification but I don't know whether it intends to become a full ES:Harmony compiler.
Since the aim is to to compile ES6 down to ES3 it would also need to support ES5 features (and probably a switch whether to compile ES5 to ES3 or ES6 to ES3).
Are there currently any other projects aiming to create a full ES:Harmony to ES3 compiler?
Is it wise to start writing such a compiler knowing that the standard is young / unstable / in flux.
Are there currently any ES5 -> ES3 compilers?
I've left a question on the Traceur mailing list.
The aim of such a compiler would be backwards compatibility with ES3. Not full emulation of ES5 and ES6 in ES3.
(shameless but relevant plug below)
Caja is reworking its ES5 support via ES5/3 and will do the same for ES harmony. So our structure would be implemented as a Harmony to ES3 layer which can be skipped for real harmony implementations, and then a separable loader that preserves the security properties that concern caja.
Like Traceur, members of the Caja team are part of TC39 (the committee defining ES Harmony).
I don't know about Coffeescript's plans, but it was mentioned during discussions of Harmony modules. Module loaders will likely have the ability to intercept loaded source code (via eval hooks) and rewrite it before module initialization, so if a module is written in CoffeeScript, a runtime CoffeeScript rewriter could be invoked at initialization time. This would allow apps to be composed of modules written in multiple languages that compile down to Harmony at load time.
One thing to note is that not everything in Harmony can be implemented easily via translation. For example, implementing weak maps correctly would require implementing your own garbage collector in JavaScript and even if you did that you would probably just reintroduce the host object/native object cycle problem.
Check out TypeScript, Microsoft's new language based on ES6.
Continuum has implemented most of the relevant features and should run in es3 browsers (like older IEs).
Mascara is probably what you're looking for.
As of the time of typing, we now have Babel. It integrates with many different build tools/systems, and will transpile ES6+ in order to support legacy browsers (it doesn't state which version it targets, but it does say that it targets IE9+).
To install it type npm install babel -g.
Note that it has rather a lot of dependencies and when installed it is ~23.4 MB (2888 files).
Google Closure Compiler (Github) is a great tool for ES6 compilation. It's a simple Java jar that is used from the command line. There are other options such as API services and GUIs, but I find that it was best to set up an automatic build system hooking into the Java JAR. It can transpile your ES6 code into ES5 compatible code. I started using it for compressing and obfuscating code, but it can also do error checking and the ES6 transpilation as I mentioned.
Note that the ES6 features are marked as experimental. But I'm planning on using them in production soon, since my tests were rock solid.
There's also https://github.com/matthewrobb/six
Six is a language super-set of JavaScript that enables new syntactic features from the 6th edition of ECMAScript to be used, through a transpiler, in your scripts today.
WARNING: Still in a very early state, proceed with caution.
I'm not sure in what instance compilation back to ES3 would valuable as opposed to ES5, seeing that implementation changes are limited to array and object helper functions, and ES5 support is so prevalent.
So for completeness, another ES6 to ES5 compiler is the esnext project by Square. It is a collection of a number of modules designed to polyfill various ES6 features provided in one package. Here is the list modules included: https://github.com/square/esnext#available